This commit yields a Lexer.hs that doesn't compile when using alex-3.5.1.0 (prevailing version on Hackage). Errors look like
compiler/GHC/Parser/Lexer.x:2871:20: error: [GHC-88464]
Data constructor not in scope: C# :: t0 -> Char
Suggested fixes:
• Perhaps use one of these:
‘GHC.Exts.C#’ (imported from GHC.Exts),
‘GHC.Exts.D#’ (imported from GHC.Exts),
‘GHC.Exts.F#’ (imported from GHC.Exts)
• Perhaps you want to add ‘C#’ to the import list in the import of
‘GHC.Exts’
i also have a concern that ghc-9.8.2 doesn't appear to install with stack on ubuntu generating the error
Preparing to install GHC (tinfo6) to an isolated location. This will not interfere with any
system-level installation.
Preparing to download ghc-tinfo6-9.8.2 ...
Download expectation failure: ContentLength header
Expected: 214363160
Actual: 213956760
For: https://downloads.haskell.org/ghc/9.8.2/ghc-9.8.2-x86_64-fedora33-linux.tar.xz
(see e.g. https://github.com/shayne-fletcher/ghc-lib/pull/236/checks?check_run_id=21960246906)
closing in favor of !11942 (closed)
Fixes issue "autoconf-2.72 breaks macOS configure" #24324
@alt-romes i gave it a go and for ghc-lib's purposes (the context in which i encountered this issue), this fix works!
the tooling that produces ghc-lib uses stack to build hadrian and it would be some amount of work to change that
can i leave furthering this with you @alt-romes ? do please let me know how you think best we proceed!
Fixes issue "autoconf-2.72 breaks macOS configure" #24324
Shayne Fletcher (e9214289) at 10 Jan 16:24
fixes autoconf-2.72 issue #24324
autoconf 2.72 was released fri, 22 dec 2023 1. brew reports 2.72 as the current version of autoconf 2.
using autoconf-2.72, azure with image "macOS-latest" (Big Sur 3) AC_PROG_CXX
on azure/macOS appears to set CXX
to /usr/bin/g++ -std=gnu++11
.
in 'm4/fp_find_cxx_lib.m4' the code "$CXX" -E actest.cpp -o actest.out
results in error no such file or directory: /usr/bin/g++ -std=gnu++11
. if we instead write eval "$CXX" -E actest.cpp -o actest.out
it works the way we want.
I think this would be a good idea.
What
alex
version deprecated-v
?
3.5.0.0
Does this still work for those old versions?
Yes.
Perhaps another idea is to use the
--version
flag which apparently works for all versions?
This is an equivalent fix.
Fixes #24302
In fptools_alex.m4, use -V
to check for Alex version instead of -v
since the latter is deprecated and repurposed for --verbose
in recent Alex versions.
i found this page on the wiki about creating merge requests https://gitlab.haskell.org/ghc/ghc/-/wikis/Contributing-a-Patch and this page with more general information for new contributors https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#newcomers-to-ghc. hope this helps!
fork, create a branch, fix it on your branch & submit an MR from your branch on your fork. link this issue in the MR.
i think it unlikely you'll be challenged for repo access (and if you are we'll work out how to fix it).
no issues! thanks @Bodigrim @BinderDavid. i'll close this out.
hpc-0.6.2 on hackage doesn't build with ghc-9.6.2 (because constraint base < 4.18).
❯ cabal get hpc-0.6.2.0 && cd hpc-0.6.2.0 && cabal new-build hpc
Unpacking to hpc-0.6.2.0/
Resolving dependencies...
Error: cabal: Could not resolve dependencies:
[__0] trying: hpc-0.6.2.0 (user goal)
[__1] next goal: base (dependency of hpc)
[__1] rejecting: base-4.18.0.0/installed-4.18.0.0 (conflict: hpc =>
base>=4.4.1 && <4.18)
[__1] skipping: base-4.18.0.0 (has the same characteristics that caused the
previous version to fail: excluded by constraint '>=4.4.1 && <4.18' from
'hpc')
[__1] rejecting: base-4.17.1.0, base-4.17.0.0, base-4.16.4.0, base-4.16.3.0,
base-4.16.2.0, base-4.16.1.0, base-4.16.0.0, base-4.15.1.0, base-4.15.0.0,
base-4.14.3.0, base-4.14.2.0, base-4.14.1.0, base-4.14.0.0, base-4.13.0.0,
base-4.12.0.0, base-4.11.1.0, base-4.11.0.0, base-4.10.1.0, base-4.10.0.0,
base-4.9.1.0, base-4.9.0.0, base-4.8.2.0, base-4.8.1.0, base-4.8.0.0,
base-4.7.0.2, base-4.7.0.1, base-4.7.0.0, base-4.6.0.1, base-4.6.0.0,
base-4.5.1.0, base-4.5.0.0, base-4.4.1.0, base-4.4.0.0, base-4.3.1.0,
base-4.3.0.0, base-4.2.0.2, base-4.2.0.1, base-4.2.0.0, base-4.1.0.0,
base-4.0.0.0, base-3.0.3.2, base-3.0.3.1 (constraint from non-upgradeable
package requires installed instance)
[__1] fail (backjumping, conflict set: base, hpc)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, hpc
if allow-newer is given then
cabal get hpc-0.6.2.0 && cd hpc-0.6.2.0 && cabal new-build hpc --allow-newer
Unpacking to hpc-0.6.2.0/
Resolving dependencies...
Build profile: -w ghc-9.6.2 -O1
In order, the following will be built (use -v for more details):
- hpc-0.6.2.0 (lib) (first run)
Configuring library for hpc-0.6.2.0..
Preprocessing library for hpc-0.6.2.0..
Building library for hpc-0.6.2.0..
[1 of 4] Compiling Trace.Hpc.Util ( Trace/Hpc/Util.hs, /Users/shayne/tmp/hhh/hpc-0.6.2.0/hpc-0.6.2.0/hpc-0.6.2.0/hpc-0.6.2.0/dist-newstyle/build/x86_64-osx/ghc-9.6.2/hpc-0.6.2.0/build/Trace/Hpc/Util.o, /Users/shayne/tmp/hhh/hpc-0.6.2.0/hpc-0.6.2.0/hpc-0.6.2.0/hpc-0.6.2.0/dist-newstyle/build/x86_64-osx/ghc-9.6.2/hpc-0.6.2.0/build/Trace/Hpc/Util.dyn_o )
Trace/Hpc/Util.hs:35:1: error: [GHC-44360]
System.Directory: Can't be safely imported!
The module itself isn't safe.
|
35 | import System.Directory (createDirectoryIfMissing)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error: cabal: Failed to build hpc-0.6.2.0.
it can be built like this
cabal get hpc-0.6.2.0 && cd hpc-0.6.2.0 && cabal new-build hpc --allow-newer --ghc-options=-fno-safe-haskell
but when it's a build dependency (of say, ghc-lib), it's not obvious how to pass -fno-safe-haskell
without resorting to a cabal.project file (is there any other way?)
i haven't tried that. i can give it a go. let's see. i'll report back.
yes, i need this to work with directory-1.3.8.1. in fact, full disclosure, we need this set to work
- unix-2.8.1.1
- directory-1.3.8.1
- process-1.6.17.0
- filepath-1.4.100.4
- hpc-0.6.2.0 # will fail for directory bounds and safe haskell issue
# this works great!
# - git: https://gitlab.haskell.org/hpc/hpc.git
# commit: 50d520bf6002ab55032e233dced0556ad63ad0c0
- Win32-2.13.4.0
- time-1.12.2
- semaphore-compat-1.0.0
this is induced by ghc's new dependence on semaphore-compat-1.0.0.