- ghc-devs - Haskell.org

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

19 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 17 Mar '26

17 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

Re: [Haskell-cafe] Re: Cabal transitive constraint puzzle
by Brandon Allbery 06 Mar '26

06 Mar '26

It used to be, but cryptonite has been unmaintained for a couple of years now and that's somewhat bad for a security-related package. On Thu, Mar 5, 2026 at 2:55 PM Roland Lutz <rlutz(a)hedmen.org> wrote: > On Fri, 6 Mar 2026, Viktor Dukhovni wrote: > > Bottom line, the two variants of `mlkem` don't end up offering the same > > API (distinct type signatures, that only look the same). > > Isn't this exactly what Backpack modules are for? If `mlkem` and `tls` > imported a signature for `crypton`/`cryptonite`, depending on either of > these should have `mlkem` and `tls` use the correct version of the API. > > I'm not sure what to make of "somewhat experimental", though: > https://cabal.readthedocs.io/en/stable/how-to-use-backpack.html > > > It may already have been considered, but wouldn't making `tls` compatible > with `cryptonite` solve the issue, too? > > _______________________________________________ > Haskell-Cafe mailing list -- haskell-cafe(a)haskell.org > To (un)subscribe, modify options or view archives go to: > Only members subscribed via the mailman list are allowed to post. > -- brandon s allbery kf8nh allbery.b(a)gmail.com

1 0

Call for Talks: Haskell Implementors' Workshop 2026
by Christiaan Baaij 20 Feb '26

20 Feb '26

Haskell Implementors' Workshop 2026 https://haskell.foundation/events/2026-haskell-implementors-workshop.html June 5, 2026 Organized by the Haskell Community Co-located with ZuriHac 2026 and Haskell Ecosystem Workshop 2026 Hosted by the Haskell Foundation at Eastern Switzerland University of Applied Sciences (OST) https://www.ost.ch/en/university-of-applied-sciences/campus/rapperswil-jona… Important dates --------------- Deadline: April 10, 2026 (AoE) Notification: May 8, 2026 Workshop: June 5, 2026 The 18th Haskell Implementors' Workshop is to be held alongside ZuriHac 2026 this year near Zurich. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure to share their work and to discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and short lightning talks. Scope and target audience ------------------------- The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community are encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are especially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via this form https://forms.gle/S8fpAgFaFEvqoMqH6 until April 10 (anywhere on earth). We will also have a lightning talks session. Lightning talks should be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee ----------------- * Andrew Lelechenko * Avi Press * Christiaan Baaij (chair) * Gergo Erdi * Jeffrey Young Contact ------- * Christiaan Baaij <chrisitaan.baaij at gmail.com>

1 0