- ghc-devs - Haskell.org

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 31 Mar '26

31 Mar '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

GHC 9.12.4 is now available
by Zubin Duggal 27 Mar '26

27 Mar '26

The GHC developers are very pleased to announce the release of GHC 9.12.4. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][] and via [GHCup](https://www.haskell.org/ghcup/). GHC 9.12.4 is a bug-fix release fixing many issues of a variety of severities and scopes, including: * Fixed a critical code generation regression where sub-word division produced incorrect results (#26711, #26668), similar to the bug fixed in 9.12.2 * Numerous fixes for register allocation bugs, preventing data corruption when spilling and reloading registers (#26411, #26526, #26537, #26542, #26550) * Fixes for several compiler crashes, including issues with CSE (#25468), and the simplifier(#26681), implicit parameters (#26451), and the type-class specialiser (#26682) * Fixed cast worker/wrapper incorrectly firing on INLINE functions (#26903) * Fixed LLVM backend miscompilation of bit manipulation operations (#20645, #26065, #26109) * Fixed associated type family and data family instance changes not triggering recompilation (#26183, #26705) * Fixed negative type literals causing the compiler to hang (#26861) * Improvements to determinism of compiler output (#26846, #26858) * Fixes for eventlog shutdown deadlocks (#26573) and lost wakeups in the RTS (#26324) * Fixed split sections support on Windows (#26696, #26494) and the LLVM backend (#26770) * Fixes for the bytecode compiler, PPC native code generator, and Wasm backend * The runtime linker now supports COMMON symbols (#6107) * Improved backtrace support: backtraces for `error` exceptions are now evaluated at throw time * `NamedDefaults` now correctly requires the class to be standard or have an in-scope default declaration, and handles poly-kinded classes (#25775, #25778, #25882) * ... and many more A full accounting of these fixes can be found in the [release notes][]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. GHC development is sponsored by: * [Juspay](https://juspay.com/) * [QBayLogic](https://qbaylogic.com/) * [Channable](https://www.channable.com/) * [Haskell Foundation](https://haskell.foundation/) * [Serokell](https://serokell.io/) * [Well-Typed](https://well-typed.com/) * [Tweag](https://www.tweag.io/) * [Dotcom-Monitor](https://www.dotcom-monitor.com/) * [LoadView](https://www.loadview-testing.com/) * [Web Hosting Buddy](https://webhostingbuddy.com/) * [Find My Electric](https://www.findmyelectric.com/) * [Standard Chartered](https://www.sc.com) * [UpCloud](https://upcloud.com) * [Mercury](https://mercury.com) We would like to thank these sponsors and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. [release notes]: https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.12/docs/users_guide/9.12.4-… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.12.4 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

Re: Strange "Unknown flag" message
by Simon Peyton Jones 25 Mar '26

25 Mar '26

> > I think to avoid this you will need to be careful to only apply these > flags when the BOOTSTRAP_TH flag is set. > In particular, I think what's happening is that we try to find the > GHC.KnownKey module and then start pulling in all of ghc-internal. Ah yes. The command line does indeed invoke the *bootstrap *compiler, which of course does now know these flags. *But what business does the bootstrap compiler have with compiling GHC.Internal.Classes? * I would be entirely unsurprised if the bootstrap compiler stumbled on compiling a module that is so closely coupled to GHC's internals. Simon On Wed, 25 Mar 2026 at 13:02, Teo Camarasu <teo(a)informal.codes> wrote: > Hi Simon, > > Note that this is occurring while compiling `ghc-boot-th-next`. This > package vendors the TemplateHaskell interfaces from ghc-internal and is > built by the boot compiler. You will find a bunch of CPP in the > TemplateHaskell modules like `GHC.Internal.TH.Syntax` that switches out > `ghc-internal` imports for `base` imports when bootstrapping so we can > compile with the boot compiler. For more context see `Note [Bootstrapping > Template Haskell]`. > > I think to avoid this you will need to be careful to only apply these > flags when the BOOTSTRAP_TH flag is set. > In particular, I think what's happening is that we try to find the > GHC.KnownKey module and then start pulling in all of ghc-internal. > > Cheers, > Teo > > On Wed, 25 Mar 2026, at 12:56 PM, Brandon Allbery via ghc-devs wrote: > > I'd suspect it's your boot compiler producing that error, and that what > changed might have been the file being compiled, causing a recompile with > the wrong compiler? > > On Wed, Mar 25, 2026 at 8:53 AM Simon Peyton Jones via ghc-devs < > ghc-devs(a)haskell.org> wrote: > > Friends > > After 10 days of working on !15719 I have suddenly started getting > > /home/simonpj/code/HEAD-19/libraries/ghc-boot-th-next/../ghc-internal/src/GHC/Internal/Classes.hs:10:17: > error: [GHC-04924] > Unknown flag in {-# OPTIONS_GHC #-} pragma: -fdefines-known-key-names > | > 10 | {-# OPTIONS_GHC -fdefines-known-key-names #-} > | ^^^^^^^^^^^^^^^^^^^^^^^^^ > > I have no idea why this was fine until 10am this morning, and has suddenly > started happening now. > > *How does GHC decide what runtime flags it allows? * > `-fdefines-known-key-names` is in GHC.Driver.Session.fFlagsDeps. > > > I'm boggled that it worked until 10am and then abruptly stopped. > > Any advice? > > Simon > > _______________________________________________ > ghc-devs mailing list -- ghc-devs(a)haskell.org > To unsubscribe send an email to ghc-devs-leave(a)haskell.org > > > > -- > brandon s allbery kf8nh > allbery.b(a)gmail.com > _______________________________________________ > ghc-devs mailing list -- ghc-devs(a)haskell.org > To unsubscribe send an email to ghc-devs-leave(a)haskell.org > > >

3 7

Strange "Unknown flag" message
by Simon Peyton Jones 25 Mar '26

25 Mar '26

Friends After 10 days of working on !15719 I have suddenly started getting /home/simonpj/code/HEAD-19/libraries/ghc-boot-th-next/../ghc-internal/src/GHC/Internal/Classes.hs:10:17: error: [GHC-04924] Unknown flag in {-# OPTIONS_GHC #-} pragma: -fdefines-known-key-names | 10 | {-# OPTIONS_GHC -fdefines-known-key-names #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^ I have no idea why this was fine until 10am this morning, and has suddenly started happening now. *How does GHC decide what runtime flags it allows? * `-fdefines-known-key-names` is in GHC.Driver.Session.fFlagsDeps. I'm boggled that it worked until 10am and then abruptly stopped. Any advice? Simon

3 2

GHC 9.12.4-rc1 is now available
by Zubin Duggal 18 Mar '26

18 Mar '26

The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.12.4. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][] and via [GHCup](https://www.haskell.org/ghcup/). GHC 9.12.4 is a bug-fix release fixing many issues of a variety of severities and scopes, including: * Fixed a critical code generation regression where sub-word division produced incorrect results (#26711, #26668), similar to the bug fixed in 9.12.2 * Numerous fixes for register allocation bugs, preventing data corruption when spilling and reloading registers (#26411, #26526, #26537, #26542, #26550) * Fixes for several compiler crashes, including issues with CSE (#25468), SetLevels (#26681), implicit parameters (#26451), and the type-class specialiser (#26682) * Fixed cast worker/wrapper incorrectly firing on INLINE functions (#26903) * Fixed LLVM backend miscompilation of bit manipulation operations (#20645, #26065, #26109) * Fixed associated type family and data family instance changes not triggering recompilation (#26183, #26705) * Fixed negative type literals causing the compiler to hang (#26861) * Improvements to determinism of compiler output (#26846, #26858) * Fixes for eventlog shutdown deadlocks (#26573) and lost wakeups in the RTS (#26324) * Fixed split sections support on Windows (#26696, #26494) and the LLVM backend (#26770) * Fixes for the bytecode compiler, PPC native code generator, and Wasm backend * The runtime linker now supports COMMON symbols (#6107) * Improved backtrace support: backtraces for `error` exceptions are now evaluated at throw time * `NamedDefaults` now correctly requires the class to be standard or have an in-scope default declaration, and handles poly-kinded classes (#25775, #25778, #25882) * ... and many more A full accounting of these fixes can be found in the [release notes][]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. This release candidate will have a two-week testing period. If all goes well the final release will be available the week of 26 March 2026. GHC development is sponsored by: * [Juspay](https://juspay.com/) * [QBayLogic](https://qbaylogic.com/) * [Channable](https://www.channable.com/) * [Haskell Foundation](https://haskell.foundation/) * [Serokell](https://serokell.io/) * [Well-Typed](https://well-typed.com/) * [Tweag](https://www.tweag.io/) * [Dotcom-Monitor](https://www.dotcom-monitor.com/) * [LoadView](https://www.loadview-testing.com/) * [Web Hosting Buddy](https://webhostingbuddy.com/) * [Find My Electric](https://www.findmyelectric.com/) * [Standard Chartered](https://www.sc.com) * [UpCloud](https://upcloud.com) * [Mercury](https://mercury.com) We would like to thank these sponsors and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. [release notes]: https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.12/docs/users_guide/9.12.4-… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.12.4-rc1 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

2 4

Wrapping up GHC work next week
by Matthew Pickering 17 Mar '26

17 Mar '26

Hi all, Since my last day working on GHC will be next Tuesday (24th March), I'll be unassigning myself from all the issues I'm currently assigned to and closing my open PRs. Thank you all for the collaboration over the last 11 years of working on the project. My first commit was all the way back in March 2015 and since then I've contributed over 1000 commits to the compiler, it's been quite a journey! This also means that I’m unlikely to be available for reviewing patches or commenting on issues after next week. If there is anything high priority that would particularly benefit from my input before then, please let me know. Cheers, Matt

2 1

GHC extensions
by Simon Peyton Jones 16 Mar '26

16 Mar '26

Friends As part of the reinstallable base project I'm adding an extension "ImplicitKnownKeyNames" to GHC. But if I put "NoImplicitKnownKeyNames" in base.cabal.in I get the error Warning: [unknown-extension] Unknown extensions: NoImplicitKnownKeyNames when building the base library. I think this comes from cabal. How can I tell cabal about the new extension? Thanks Simon

6 15

Upcoming ghc-10.0 (formerly 9.16) fork date
by Andreas Klebinger 06 Mar '26

06 Mar '26

Hello devs, time marches and so do our plans for future releases. We plan to fork the 10.0 branch on April 1st (no not a joke). If you have work you want to see land in 10.0 please try to land it on ghc-master before that time, as we plan to do no *feature* backports beyond that point. Bugfixes of course will continue to be backport beyond the fork date. If you wonder about the supermajor version bump this was discussed in https://gitlab.haskell.org/ghc/ghc/-/issues/26198. And while ghc-10.0 will come with great features, the primary motivation is simple. Every LTS will be the last major release of a given supermajor version going forward. (9.14 being the first official LTS). This has a few benefits and overall just seemed like the least confusing option: * The last major release of any supermajor version will be it's LTS release. * The LTS release for a supermajor version will have all features present in any other major release of that supermajor release (deprecations excluded) Happy Hacking Andreas

1 0

Cabal transitive constraint puzzle
by Viktor Dukhovni 06 Mar '26

06 Mar '26

Dear Cafe and GHC-devs, I am happy to see that Yamamoto-san (cc:d) (the maintainer of the `tls` package) is extending it to include support for MLKEM key agreement. This in turn depends on the `mlkem` library by Olivier Chéron (also many thanks!). Now it turns out that for maximum portability, `mlkem` in turn has a build flag `use_crypton` that selects either `crypton`, or (current default) the older `cryptonite` library as its dependency. So the dependen graph is: tls <- mlkem <- if (use_crypton): crypton else: cryptonite But, at this, point `tls` is crypton-only, and no longer builds with the older cryptonite equivalents. Therefore `tls` adds constraints: mlkem +use_crypton to its `cabal.project` file, which solves the problem for `tls`, but sadly not for any projects that in turn depend on `tls`. To them the constraints in the `cabal.project` file of `tls` are effectively invisible. Since the default flag value in `mlkem` is for now `use_crypton: false`, each project that wants to use the (work-in-progress) `tls` appears to need to explictly know that `tls` requires a non-default build of `mlkem`, and must add the same constraints to its `cabal.project`. That transitive explicit configuration requirement is not something one can reasonably ask projects that depend on `tls to have to add. And of course, more generally, any other such indirect flag-dependent conflict must not become a burden on all consumers of library B that is only compatible with a specific variant of library C. How is this situation supposed to be handled? Is there something in cabal that can automatically convince the solver to select a setting of the `mlkem` flag that is compatible with `tls`? Must `mlkem` be forked instead to be two libraries, one dependent on `cryptonite` and another dependent on `crypton`? I've been unable to find a satisfactory workaround. Any help appreciated. -- Viktor.

5 12