- ghc-devs - Haskell.org

Reinstallable base failure -- help
by Simon Peyton Jones 15 Apr '26

15 Apr '26

Friends I'm working on !15719, which is a big step towards making `base` reinstallable. But in one build I'm getting a strange failure, below, just in one build x86_64-linux-fedora43-release https://gitlab.haskell.org/ghc/ghc/-/jobs/2484333 Now, it's likely that this failure is due to my patch. *But I can't reproduce it locally*. How can I repo? I tried hadrian/build --flavour=release but that didn't fall over. Thanks! Simon * Raised the exception: Development.Shake.cmd, system command failed Command line: _build/stage1/bin/haddock --verbosity=0 -B_build/stage1/lib --lib=_build/stage1/lib --odir=_build/doc/html/libraries/ghc-internal-9.1500.0 --dump-interface=_build/doc/html/libraries/ghc-internal-9.1500.0/ghc-internal.haddock --html '--title=ghc-internal-9.1500.0: Basic libraries' --prologue=_build/doc/html/libraries/ghc-internal-9.1500.0/haddock-prologue.txt --optghc=-D__HADDOCK_VERSION__=2300 --hide=GHC.Internal.IO.Handle.Lock.Common --hide=GHC.Internal.IO.Handle.Lock.Flock --hide=GHC.Internal.IO.Handle.Lock.LinuxOFD --hide=GHC.Internal.IO.Handle.Lock.NoOp --hide=GHC.Internal.IO.Handle.Lock.Windows --hide=GHC.Internal.Event.Arr --hide=GHC.Internal.Event.Array --hide=GHC.Internal.Event.Internal --hide=GHC.Internal.Event.Internal.Types --hide=GHC.Internal.Event.IntTable --hide=GHC.Internal.Event.IntVar --hide=GHC.Internal.Event.PSQ --hide=GHC.Internal.Event.Unique --hide=GHC.Internal.Unicode.Bits --hide=GHC.Internal.Unicode.Char.DerivedCoreProperties --hide=GHC.Internal.Unicode.Char.UnicodeData.GeneralCategory --hide=GHC.Internal.Unicode.Char.UnicodeData.SimpleLowerCaseMapping --hide=GHC.Internal.Unicode.Char.UnicodeData.SimpleTitleCaseMapping --hide=GHC.Internal.Unicode.Char.UnicodeData.SimpleUpperCaseMapping --hide=GHC.Internal.System.Environment.ExecutablePath --hide=GHC.Internal.Bignum.Backend.GMP --hide=GHC.Internal.Event.Control --hide=GHC.Internal.Event.EPoll --hide=GHC.Internal.Event.KQueue --hide=GHC.Internal.Event.Manager --hide=GHC.Internal.Event.Poll --hide=GHC.Internal.Event.Thread --hide=GHC.Internal.Event.TimerManager --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-hide-all-packages --optghc=-no-user-package-db '--optghc=-package-env -' '--optghc=-this-unit-id ghc-internal-9.1500.0-7cec' '--optghc=-this-package-name ghc-internal' '--optghc=-package-id rts-1.0.3' --optghc=-i --optghc=-i/builds/ghc/ghc/_build/stage1/libraries/ghc-internal/build --optghc=-i/builds/ghc/ghc/_build/stage1/libraries/ghc-internal/build/autogen --optghc=-i/builds/ghc/ghc/libraries/ghc-internal/src --optghc=-Irts/include --optghc=-I_build/stage1/libraries/ghc-internal/build --optghc=-I_build/stage1/libraries/ghc-internal/build/include --optghc=-Ilibraries/ghc-internal/include --optghc=-I/builds/ghc/ghc/rts/include --optghc=-I/builds/ghc/ghc/_build/stage1/rts/build/include --optghc=-I/builds/ghc/ghc/libraries/libffi-clib/src/x86 --optghc=-I/builds/ghc/ghc/_build/stage1/libraries/libffi-clib/build/src/x86 --optghc=-I/builds/ghc/ghc/libraries/libffi-clib/include --optghc=-I/builds/ghc/ghc/_build/stage1/libraries/libffi-clib/build/include --optghc=-optP-include --optghc=-optP_build/stage1/libraries/ghc-internal/build/autogen/cabal_macros.h --optghc=-optP-DBIGNUM_GMP --optghc=-outputdir --optghc=_build/stage1/libraries/ghc-internal/build --optghc=-package-env=- --optghc=-this-unit-id --optghc=ghc-internal --optghc=-frebindable-known-key-names --optghc=-Wcompat --optghc=-Wnoncanonical-monad-instances --optghc=-XHaskell2010 --optghc=-XNoImplicitPrelude --optghc=-no-global-package-db --optghc=-package-db=/builds/ghc/ghc/_build/stage1/inplace/package.conf.d --optghc=-ghcversion-file=rts/include/ghcversion.h --optghc=-ghcversion-file=rts/include/ghcversion.h --optghc=-package-env=- --optghc=-this-unit-id --optghc=ghc-internal --optghc=-frebindable-known-key-names --optghc=-Wcompat --optghc=-Wnoncanonical-monad-instances --optghc=-XHaskell2010 --optghc=-XNoImplicitPrelude --optghc=-no-global-package-db --optghc=-package-db=/builds/ghc/ghc/_build/stage1/inplace/package.conf.d --optghc=-ghcversion-file=rts/include/ghcversion.h --optghc=-ghcversion-file=rts/include/ghcversion.h --optghc=-Wno-deprecated-flags --optghc=-Wno-trustworthy-safe +RTS -t_build/stage1/haddock-timing-files/ghc-internal.t --machine-readable -RTS --hyperlinked-source --hoogle --quickjump @/tmp/extra-file-93748803258994-2958-12008 Exit code: 1 Stderr: libraries/ghc-internal/src/GHC/Internal/Types.hs:1:1: error: [GHC-58427] attempting to use module ‘ghc-internal-9.1500.0:GHC.Internal.Types’ (libraries/ghc-internal/src/GHC/Internal/Types.hs) which is not loaded | 1 | {-# LANGUAGE Trustworthy #-} -- So that we can import in into Safe modules | ^ Build failed.

4 6

Inplace libraries
by Simon Peyton Jones 15 Apr '26

15 Apr '26

Dear devs I have thirty or so builds of GHC on my disk. Sometimes I want to use one build to build and install (for that build alone) a bunch of libraries. If I do cabal install hspec -w $HOME/code/HEAD-22/_build/stage1/bin/ghc then Cabal rightly warns me Warning: The libraries were installed by creating a global GHC environment file at: /home/simonpj/.ghc/x86_64-linux-9.15.20260309/environments/default The presence of such an environment file is likely to confuse or break other tools because it changes GHC's behaviour: it changes the default package set in ghc and ghci from its normal value (which is "all boot libraries"). GHC environment files are little-used and often not tested for. Question: how can I install the libraries in the build tree for $HOME/code/HEAD-22? After all, I think ghc-internal, base etc are all in that build-tree. Surely hspec can be too? But how? Thanks! Simon

4 8

Gitlab API and web rate limiting for unauthenticated users
by Magnus Viernickel 14 Apr '26

14 Apr '26

Dear GHC devs, as part of my effort to increase the usability of our gitlab instance, I have started employing rate limiting for unauthenticated API requests. The majority of the traffic on the machine and the reason why you experience slowness is disrespectful crawlers that hit expensive API endpoints (hundreds of requests per second look at random commits). Previously they were allowed to do this multiple times per second for hours and hours. Now they get a more modest but still very generous budget. If you're using the API unauthenticated with scripts and hit rate limits, please consider if you really have to hammer it that hard. If you really can't get around sending so many requests, you may use an API token. Authenticated requests are currently almost not rate limited at all. If this turns out to be to impairing for users, I will increase the limits. Best Magnus

1 0

Rotation of Marge's SSH key
by Magnus Viernickel 13 Apr '26

13 Apr '26

Hello GHC developers, For security reasons we have rotated Marge-Bot's SSH key. If you notice any issues that could have been caused by this change, please do not hesitate to reach out. Best Magnus

1 0

GHC change logs
by Simon Peyton Jones 12 Apr '26

12 Apr '26

Friends As part our efforts to ship a more complete and comprehensive > release notes for the next major release, we would > appreciate cooperation in not assigning Marge for MRs that > don't have a changelog and make user visible changes. If your > MR truly does not need a changelog entry, label it 'no-changelog'. Just to add a PS to Zubin's post, he is highlighting a real change to GHC's CI system: - *In future, when you submit a merge request (MR) for GHC, you will need to provide a change-log entry (almost always)* Why? It's so that every GHC release comes with a complete list of all the changes that have been made in that release. As things stand, the release manager makes a best-efforts attempt to summarise the stream of MRs, but that person isn't necessarily familiar with the specifics and may well miss important stuff. Plus it is a painful and laborious task. It's not hard: a change-log entry is just a short file with a simple summary of the change. Details on this page <https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing/changelog>. It does add a little bit of friction, but not much compared to the effort of finding and fixing the bug! This is all part of our main page on how to contribute a patch to GHC <https://gitlab.haskell.org/ghc/ghc/-/wikis/Contributing-a-Patch>. I am truly grateful to you for contributing to GHC. I mean it: GHC only flourishes because lots of generous people offer their time to make it happen. Thank you! Simon

1 0

Upcoming fork for GHC 10.0, new changelog system for GHC 10.1
by Zubin Duggal 11 Apr '26

11 Apr '26

Hi all, We plan to fork for GHC 10.0 next week on Thursday (April 9th). Please make sure any merge requests you would like to see merged are merged in time for the fork. If the merge request is particularly important, and you are confident it is ready for a merge, please let me know by responding to this email, and I will do my best in trying to land it before the fork. If a merge request is still incomplete but fixes a critical bug we should fix in GHC 10.0, mark it with the backport needed:10.0 label and we will consider it for backporting. After the GHC 10.0 fork, master will be bumped to GHC 10.1. Any MRs that land after this point will require changelog entries, according to the scheme implemented in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/15830 This will require all MRs, unless tagged with "no-changelog" label (reserved for entirely non user facing changes like CI), to populate an entry in the changelog.d/ directory. You will need to create a file with a descriptive name, based on your changes, for instance (picking a patch that recently landed): changelog.d/fix-datakindsinfix: ``` section: language synopsis: Fix a bug where GHC would erroneously accept infix promoted data constructors without enabling :extension:`DataKinds`. issues: #26737 mrs: !15609 description: { As a result, you may need to enable :extension:`DataKinds` in code that did not previously require it. } ``` The `section` field controls what section of the release notes your entry ends up in, available sections are defined in changelog.d/config (https://gitlab.haskell.org/ghc/ghc/-/blob/05ddce3b88cfe9729811c4ce843c8ccbe…) The `synopsis` field is a brief description of the change. This is the main payload `issues` is a space seperated list of issues fixed by the change `mrs` is a space seperated list of mrs. If you are modifying a feature which already has a changelog entry, add your MR to the `mrs` list for the existing entry instead of creating a new changelog entry. `description` is an optional field where you can expand on the description of your change. It will be rendered on a new line following the `synopsis` entry in the changelog. Both `section` and `description` accept the existing RST syntax we use for release notes entries. A new CI job ensures that each patch (unless otherwise labeled) touches a properly formatted changelog file with an `mrs` field including the MR number of the patch. This job will not block subsequent build/validation jobs from running, but it will be needed to pass before Marge can pick up the MR for merging. If you have any questions or feedback about this system, now is the time to give it. It will be much easier adding any additional metadata we might want to track in changelog entries now, rather than after the fork. Thanks, Zubin.

1 3

Loss of debug output
by Simon Peyton Jones 04 Apr '26

04 Apr '26

Suddenly, after pulling today's patches, my standard workflow doesn't work. - -ddump-simpl no longer shows the simplified Core - -dverbose-core2core no longer shows the output of each pass What has happened?? Thanks Simon

1 1

If static001 fails on darwin, please rebase
by Magnus Viernickel 04 Apr '26

04 Apr '26

Dear GHC devs, I have recently updated the darwin (MacOS) runners to a newer OS and toolchain. That caused a test called static001 to fail. I have landed a fix. If your MR pipelines fail on darwin because of static001, you can fix this issue by rebasing on origin/master. I am sorry for the inconvenience caused. Thanks everyone for your patience. I am seeing a light at the end of the tunnel of bringing things up to date, you almost made it! Have a nice weekend. Best Magnus

1 0

Boot libraries for GHC 10.0
by Zubin Duggal 02 Apr '26

02 Apr '26

Hi all, The GHC 10.0 branch is scheduled to be cut next week. You are receiving this email because you are listed as a maintainer on a boot library or have uploaded a version to hackage recently. Below are the current versions of all boot libraries and submodules in the GHC tree. Libraries behind Hackage: - file-io: 0.1.5 in tree, 0.2.0 on Hackage - filepath: 1.5.4.0 in tree, 1.5.5.0 on Hackage - os-string: 2.0.8 in tree, 2.0.10 on Hackage - process: 1.6.26.1 in tree, 1.6.27.0 on Hackage Unless there are objections, we will attempt to bump these four libraries to their latest Hackage versions before the fork. Libraries currently at the latest Hackage version: - Cabal 3.16.1.0 - Cabal-syntax 3.16.1.0 - Win32 2.14.2.1 - array 0.5.8.0 - binary 0.8.9.3 - bytestring 0.12.2.0 - containers 0.8 - deepseq 1.5.2.0 - directory 1.3.10.1 - exceptions 0.10.12 - haskeline 0.8.4.1 - hpc 0.7.0.2 - hsc2hs 0.68.10 - libffi-clib 3.5.2 - mtl 2.3.2 - parsec 3.1.18.0 - pretty 1.1.3.6 - semaphore-compat 1.0.0 - stm 2.5.3.1 - template-haskell-lift 0.1.0.0 - template-haskell-quasiquoter 0.1.0.0 - terminfo 0.4.1.7 - text 2.1.4 - time 1.15 - transformers 0.6.3.0 - unix 2.8.8.0 - xhtml 3000.4.0.0 I presume there will also be a corresponding Cabal 3.18 release, which we will coordinate with the Cabal developlers. Otherwise, if you would like a different version of any library to ship with GHC 10.0, please open a GHC ticket at https://gitlab.haskell.org/ghc/ghc/-/issues/new so we can track it. Thanks, Zubin

1 0

Recent Windows CI issues
by Cheng Shao 01 Apr '26

01 Apr '26

Hi GHC devs, Me and Magnus have brought up a new temporary windows runner to address the recent GHC CI traffic jam, as a part of our joint work to make CI faster. If you see your windows CI job fails with T17912, before retrying the job, please rebase your branch against the latest master branch, so that it includes latest fixes and can reliably pass on the new runner. If you spot other spurious windows CI failures, please open a new issue and tag us. Cheers, Cheng Shao

1 0