- ghc-devs - Haskell.org

Backports for 9.10.4
by Andreas Klebinger 22 May '26

22 May '26

I've started to work on preparing the 9.10.4 release. If you have patches that you think should be backported please apply the backport needed 9.10 label to the MR in question in a timely fashion. If you have other concerns about this release similarly please reach out and let me know. Currently we plan for this to be the last 9.10 release in the 9.10 series. Cheers Andreas

2 1

Backports for GHC 9.12.5
by Magnus Viernickel 21 May '26

21 May '26

Dear GHC Devs, Preparation of the GHC 9.12.5 release are well under way and I would like to ask me if there are any patches that you think should be included in that branch that haven't been marked with the respective backport label. If there is any patch, please add the label and ping me on the respective MR. Thank you so much. Best Magnus

1 0

GitLab account approval
by Jasper Reef 16 May '26

16 May '26

Hi, for a while i have been occasionally browsing the issue tracker of GHC, wondering if i might be able to get involved. Today I finally decided to just try it, by picking an issue labeled `newcomer` and spelunking through the code, until i felt like i understood just enough, to hopefully submit a helpful patch. Please approve the user `Kato-Dax`. Thanks! Jasper

1 0

Short gitlab outage
by Magnus Viernickel 15 May '26

15 May '26

Dear GHC Devs, We were having a short outage due to gitlab's background services putting on too much memory pressure and the oomkiller kicking in. To reduce the risk for this to happen, I have applied a small config change that will restart the gitlab container resulting in a few more minutes of downtime. We should be all good at 14:15 CEST. Best Magnus

1 0

Looking for maintainer: ghc-exactprint
by Alan & Kim Zimmerman 13 May '26

13 May '26

Hi all I have come to the sad realisation that I am not actually part of the Haskell ecosystem any more. I joined at a time of my life when I was doing management work with lots of free time, and needed something to occupy my brain. Haskell and contributing to GHC did that for me in spades. But for the last few years I have been working as an individual contributor, in a non-Haskell ecosystem. So my available time and motivation for Haskell has fallen off. I have always been interested in developer tooling, and refactoring in particular. My efforts to restore the Haskell Refactorer (HaRe) led, after many false starts, to implementing the Exact Print Annotations in GHC (using Trees That Grow), and the companion library to make use of it, ghc-exactprint. This library works in lockstep with GHC releases, so for every GHC (major) release there needs to be a new ghc-exactprint release. I have been doing this every release since the first one in 2015, and it is something that needs to happen for every release. Over the last few years I have got the implementation to work the way I believe it should, and that it is now stable, so any changes going forward should just be tweaks to manage the inevitable changes to the language. I follow a well-defined process[1] for each new GHC version. My plan is to do this one more time, for the impending GHC 10.0, as the branch has now been cut. During/after that I would like to hand over to some other person(s) to take responsibility for this. The sanest approach might be to move the repo fully into GHC, much like Haddock. There is one more piece I have not been able to complete. I presented a built-in CPP at the last HIW at ZuriHac[2]. Afterwards, I completed and polished the branch[3], but ran out of steam to actually land it, as it would take a lot of consistent effort to get all parties to agree on whether it is even needed, and then to land it, deal with unintended consequences, documentation, and all the myriad other things that go with adding a new major feature. The itch I was scratching with it is to be able to cleanly handle CPP in ghc-exactprint, but it has benefits for other users too, in terms of performance, and being focused only on the actual directives, so it does not munge any unrelated code that just happens to look like a CPP directive. I would be happy to do a handover/collaboration with anyone interested in taking that over. Regards Alan [1] https://github.com/alanz/ghc-exactprint/blob/master/NEW-GHC.md [2] https://alanz.github.io/hiw2025/ [3] https://gitlab.haskell.org/ghc/ghc/-/tree/wip/az/ghc-cpp

1 0

Hadrian has broken my workflow
by Simon Peyton Jones 02 May '26

02 May '26

Friends Something extremely tiresome has happened to Hadrian. When I'm compiling GHC, and I get a type error, Hadrian helpfully tells me the command line that broke. I often copy/paste that command line to re-run it, for two reasons: - It is much much faster than running Hadrian from scratch, as I repeatedly try to compile the same source file. - More important, when building libraries or the stage2 compiler, I often want to add lots of debug or tracing flags to the command line, so I can find what is wrong with the stage1 compiler. This is utterly essential. - Indeed I often make a deliberate syntax error in (say) a library module, run Hadrian, watch it fall over with that syntax error, so I get the command line. Then I fix the deliberate error and repeatedly compile that one file with lots of tracing. But now something has broken. If I re-run the command I get simonpj@PF55P26D:~/code/HEAD-31$ /home/simonpj/.ghcup/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage0/inplace/package.conf.d' '-this-unit-id ghc-10.1-inplace' '-this-package-name ghc' '-package-id array-0.5.8.0-9044' '-package-id base-4.21.0.0-ae91' '-package-id binary-0.8.9.3-25e5' '-package-id bytestring-0.12.2.0-7dd0' '-package-id containers-0.7-5a8f' '-package-id deepseq-1.5.1.0-6837' '-package-id directory-1.3.10.1-inplace' '-package-id exceptions-0.10.9-4d2e' '-package-id filepath-1.5.4.0-inplace' '-package-id ghc-boot-10.1-inplace' '-package-id ghc-boot-th-next-10.1-inplace' '-package-id ghc-heap-9.12.2-4363' '-package-id ghc-toolchain-0.1.0.0-inplace' '-package-id ghci-10.1-inplace' '-package-id hpc-0.7.0.2-inplace' '-package-id os-string-2.0.8-inplace' '-package-id process-1.6.26.1-inplace' '-package-id rts-1.0.2' '-package-id semaphore-compat-1.0.0-inplace' '-package-id stm-2.5.3.1-d35b' '-package-id text-2.1.2-ecdb' '-package-id time-1.15-inplace' '-package-id transformers-0.6.1.2-38b1' '-package-id unix-2.8.8.0-inplace' -i -i/home/simonpj/code/HEAD-31/_build/stage0/compiler/build -i/home/simonpj/code/HEAD-31/_build/stage0/compiler/build/autogen -i/home/simonpj/code/HEAD-31/compiler/ -I_build/stage0/compiler/build -I_build/stage0/compiler/build/. -Icompiler/. -I/home/simonpj/code/HEAD-31/libraries/process/include -I/home/simonpj/code/HEAD-31/_build/stage0/libraries/process/build/include -I/home/simonpj/code/HEAD-31/libraries/directory -I/home/simonpj/code/HEAD-31/_build/stage0/libraries/directory/build -I/home/simonpj/code/HEAD-31/libraries/unix/include -I/home/simonpj/code/HEAD-31/_build/stage0/libraries/unix/build/include -I/home/simonpj/code/HEAD-31/libraries/time/lib/include -I/home/simonpj/code/HEAD-31/_build/stage0/libraries/time/build/lib/include -I/home/simonpj/.ghcup/ghc/9.12.2/lib/ghc-9.12.2/lib/x86_64-linux-ghc-9.12.2-a828/bytestring-0.12.2.0-7dd0/include -I/home/simonpj/.ghcup/ghc/9.12.2/lib/ghc-9.12.2/lib/x86_64-linux-ghc-9.12.2-a828/ghc-internal-9.1202.0-1465/include -I/home/simonpj/.ghcup/ghc/9.12.2/lib/ghc-9.12.2/lib/x86_64-linux-ghc-9.12.2-a828/ghc-bignum-1.3-6db4/include -I/home/simonpj/.ghcup/ghc/9.12.2/lib/ghc-9.12.2/lib/x86_64-linux-ghc-9.12.2-a828/rts-1.0.2/include -optP-include -optP_build/stage0/compiler/build/autogen/cabal_macros.h -optP-DCAN_LOAD_DLL -outputdir _build/stage0/compiler/build -fdiagnostics-color=always -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monoid-instances -XGHC2024 -XNoImplicitPrelude -optc-Wno-error=inline -c -o _build/stage0/compiler/build/GHC/Core.o -DDEBUG -haddock -fno-warn-deprecated-flags -O +RTS -O64M -RTS -O2 @/tmp/extra-file-9558430904709-115211-0 ghc-9.12.2: panic! (the 'impossible' happened) GHC version 9.12.2: processArgs: no arg yet It's that pesky "@" thing. And of course GHC has deleted that tmp file. Super frustrating. What can I do? Do we have to use the pesky @ thing? It's just complicating things! ALSO, *all the error messages come out twice*, which is disconcerting and tiresome. See below. Thanks Simon simonpj@PF55P26D:~/code/HEAD-31$ hadrian/build -j6 --flavour=perf+assertions_stage1+no_profiled_libs+ticky_ghc+lint Warning: Specifying an absolute path to the project file is deprecated. Use --project-dir to set the project's directory. Configuration is affected by cabal.project at '/home/simonpj/code/HEAD-31/hadrian'. Up to date Warning: Specifying an absolute path to the project file is deprecated. Use --project-dir to set the project's directory. Configuration is affected by cabal.project at '/home/simonpj/code/HEAD-31/hadrian'. ]0;Starting...(/home/simonpj/code/HEAD-31) | Run Ghc CompileHs (Stage0 InTreeLibs): compiler/GHC/Core.hs => _build/stage0/compiler/build/GHC/Core.o ]0;Running for 5s [9912/37741], predicted 4m26s (1%)(/home/simonpj/code/HEAD-31) compiler/GHC/Core.hs:1680:41: error: [GHC-88464] Variable not in scope: mkTick :: CoreTickish -> CoreExpr -> CoreExpr Suggested fix: Perhaps use data constructor ‘Tick’ (line 270) | 1680 | wrapFloat (FloatTick t) body = mkTick t body | ^^^^^^ compiler/GHC/Core.hs:1682:41: error: [GHC-88464] Variable not in scope: mkSingleAltCase :: CoreExpr -> Id -> AltCon -> [Var] -> CoreExpr -> CoreExpr | 1682 | wrapFloat (FloatCase e b con bs) body = mkSingleAltCase e b con bs body | ^^^^^^^^^^^^^^^ ]0;Finished in 5.74s(/home/simonpj/code/HEAD-31) Development.Shake.cmd, system command failed Command line: /home/simonpj/.ghcup/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage0/inplace/package.conf.d' '-this-unit-id ghc-10.1-inplace' '-this-package-name ghc' '-package-id array-0.5.8.0-9044' '-package-id base-4.21.0.0-ae91' '-package-id binary-0.8.9.3-25e5' '-package-id bytestring-0.12.2.0-7dd0' '-package-id containers-0.7-5a8f' '-package-id deepseq-1.5.1.0-6837' '-package-id directory-1.3.10.1-inplace' '-package-id exceptions-0.10.9-4d2e' '-package-id filepath-1.5.4.0-inplace' '-package-id ghc-boot-10.1-inplace' '-package-id ghc-boot-th-next-10.1-inplace' '-package-id ghc-heap-9.12.2-4363' '-package-id ghc-toolchain-0.1.0.0-inplace' '-package-id ghci-10.1-inplace' '-package-id hpc-0.7.0.2-inplace' '-package-id os-string-2.0.8-inplace' '-package-id process-1.6.26.1-inplace' '-package-id rts-1.0.2' '-package-id semaphore-compat-1.0.0-inplace' '-package-id stm-2.5.3.1-d35b' '-package-id text-2.1.2-ecdb' '-package-id time-1.15-inplace' '-package-id transformers-0.6.1.2-38b1' '-package-id unix-2.8.8.0-inplace' -i -i/home/simonpj/code/HEAD-31/_build/stage0/compiler/build -i/home/simonpj/code/HEAD-31/_build/stage0/compiler/build/autogen -i/home/simonpj/code/HEAD-31/compiler/ -I_build/stage0/compiler/build -I_build/stage0/compiler/build/. -Icompiler/. -I/home/simonpj/code/HEAD-31/libraries/process/include -I/home/simonpj/code/HEAD-31/_build/stage0/libraries/process/build/include -I/home/simonpj/code/HEAD-31/libraries/directory -I/home/simonpj/code/HEAD-31/_build/stage0/libraries/directory/build -I/home/simonpj/code/HEAD-31/libraries/unix/include -I/home/simonpj/code/HEAD-31/_build/stage0/libraries/unix/build/include -I/home/simonpj/code/HEAD-31/libraries/time/lib/include -I/home/simonpj/code/HEAD-31/_build/stage0/libraries/time/build/lib/include -I/home/simonpj/.ghcup/ghc/9.12.2/lib/ghc-9.12.2/lib/x86_64-linux-ghc-9.12.2-a828/bytestring-0.12.2.0-7dd0/include -I/home/simonpj/.ghcup/ghc/9.12.2/lib/ghc-9.12.2/lib/x86_64-linux-ghc-9.12.2-a828/ghc-internal-9.1202.0-1465/include -I/home/simonpj/.ghcup/ghc/9.12.2/lib/ghc-9.12.2/lib/x86_64-linux-ghc-9.12.2-a828/ghc-bignum-1.3-6db4/include -I/home/simonpj/.ghcup/ghc/9.12.2/lib/ghc-9.12.2/lib/x86_64-linux-ghc-9.12.2-a828/rts-1.0.2/include -optP-include -optP_build/stage0/compiler/build/autogen/cabal_macros.h -optP-DCAN_LOAD_DLL -outputdir _build/stage0/compiler/build -fdiagnostics-color=always -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monoid-instances -XGHC2024 -XNoImplicitPrelude -optc-Wno-error=inline -c -o _build/stage0/compiler/build/GHC/Core.o -DDEBUG -haddock -fno-warn-deprecated-flags -O +RTS -O64M -RTS -O2 @/tmp/extra-file-80099975488219-115449-0 Exit code: 1 Stderr: compiler/GHC/Core.hs:1680:41: error: [GHC-88464] Variable not in scope: mkTick :: CoreTickish -> CoreExpr -> CoreExpr Suggested fix: Perhaps use data constructor ‘Tick’ (line 270) | 1680 | wrapFloat (FloatTick t) body = mkTick t body | ^^^^^^ compiler/GHC/Core.hs:1682:41: error: [GHC-88464] Variable not in scope: mkSingleAltCase :: CoreExpr -> Id -> AltCon -> [Var] -> CoreExpr -> CoreExpr | 1682 | wrapFloat (FloatCase e b con bs) body = mkSingleAltCase e b con bs body | ^^^^^^^^^^^^^^^ Build failed.

1 1

gitlab downtime this morning
by Magnus Viernickel 27 Apr '26

27 Apr '26

Dear GHC Devs, as you may have noticed, the gitlab went down this morning. Properly this time, so that's new, hurray! Since I am kind of running out of options, I have reinstated Anubis again. Anubis is a a service that sits in front of our gitlab and lets users solve a proof of work challenge to obtain a cookie. It doesn't really solve the issue but it adds some throttling on the client side and results look promising for now; if performance degrades again, I'll have to look for another solution. In the meantime I will also start looking into more long term solutions, with the Haskell infra team, the current state of affairs is not sustainable, as you might agree. If you have any painpoints with Anubis, please share these. I know that this is a further UX degradation and if possible I would like to keep it as small as possible. Best Magnus

1 0

GitLab
by Simon Peyton Jones 27 Apr '26

27 Apr '26

Friends Is it just me or is GHC's GitLab down? I'm getting 502 (bad gateway). Simon

2 1

Gitlab currently throwing a lot of 502s
by Magnus Viernickel 23 Apr '26

23 Apr '26

Hello GHC devs, we're seeing a lot of 502s at the moment, we're getting twice the rate of requests than normal, I am investigating what is going on and trying to fix this. Best Magnus

4 6

Short emergency gitlab downtime to apply some fixes
by Magnus Viernickel 20 Apr '26

20 Apr '26

Hi, due to the increased number of 502s caused by out of memory kills, I had to do a quick adjustment that should hopefully improve the situation. This causes the usual 5 minutes downtime of the gitlab container rebooting. Thank you for your patience. Best Magnus

1 0