- ghc-devs - Haskell.org

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

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

05 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 19 Feb '26

19 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

Delete nofib make build system.
by Andreas Klebinger 18 Feb '26

18 Feb '26

Nofib had a shake based benchmark harness that replaced the make one for some time now. With people stopping to use the make based one it eventually bit rotted. I've been doing some refactors to fix one thing or another this week. And it's clear that the way nofibs make system currently handles package dependencies (silently expecting them to be available) is depending on your pov either completely broken or just really terrible UX. And fixing this would be non-trivial. Given the classic "make boot && make" hasn't worked for years now. So I plan to delete the make build system from it completely. If anyone has reasons against this do let me now. But unless someone is at least stepping up to fix it's handling of package dependencies I plan to follow through on it's deletion in the near future. Cheers Andreas

1 0

RFC: shutdown action of typechecker plugins
by Sam Derbyshire 16 Feb '26

16 Feb '26

Dear GHC devs, and typechecker plugin authors in particular, In GHC ticket #26935 <https://gitlab.haskell.org/ghc/ghc/-/issues/26395>, I noticed that typechecker plugins were not getting run when doing pattern match checking, which was a long standing source of frustration. I fixed this in GHC MR !14797 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14797> (only present in GHC HEAD at the moment), but, as noted in GHC ticket #26839 <https://gitlab.haskell.org/ghc/ghc/-/issues/26839>, this meant that GHC is repeatedly initialising typechecker plugins for a single module (starting and stopping the plugins for each call of initTcDsForSolver by the pattern-match checker). I am proposing to change the TcPlugin datatype to split the existing "stop" action into two separate actions, "end of typechecking" and "plugin shutdown". This would allow typechecker plugins to be kept running after typechecking (for the benefit of the pattern-match checker) while upholding the invariant that typechecker plugins are initialised once per module being typechecked (modulo small caveats about certain one-off runs of the typechecker by e.g. Backpack). The current TcPlugin data type is as follows: data TcPlugin = forall s. TcPlugin { tcPluginInit :: TcPluginM s , tcPluginSolve :: s -> TcPluginSolver , tcPluginRewrite :: s -> UniqFM TyCon TcPluginRewriter , tcPluginStop :: s -> TcPluginM () -- ^ Clean up after the plugin, when exiting the type-checker. } To allow typechecker plugins to be run by the pattern-match checker, I propose to change this to: data TcPlugin = forall s. TcPlugin { tcPluginInit :: TcPluginM s , tcPluginSolve :: s -> TcPluginSolver , tcPluginRewrite :: s -> UniqFM TyCon TcPluginRewriter , tcPluginPostTc :: s -> TcPluginM () -- ^ Action to run at the end of type-checking. , tcPluginShutdown :: s -> IO () -- ^ Clean up after the plugin, after desugaring is finished. } tcPluginPostTc would run at the end of typechecking. This gives plugins a final opportunity to modify the typechecker environment before it is finalised (as e.g. the clippy plugin does <https://github.com/ArturGajowy/ghc-clippy-plugin/blob/0f97274f238b78e1117b7…>). If the plugin relies on an active session (e.g. with Z3), the post-tc action should not end the session, because the plugin might still be invoked by the pattern match checker, later, during desugaring. Some remarks: - I changed tcPluginStop to tcPluginPostTc, because it now serves a different function (an action at the end of typechecking that should *not* shut down the plugin). Keeping the same name would be confusing, I think. - The tcPluginShutdown action runs in IO only, as running in TcPluginM would require holding on to a typechecker environment during desugaring, which can cause memory leaks. - This same change would also be carried over to defaulting plugins, but not to hole fit plugins – the latter cannot affect pattern match checking. - A better solution to all of this would be to run the pattern match checker during typechecking, but that would be a significant infrastructural change to GHC. I would like feedback from authors of typechecker plugins on this proposed change. Thanks, Sam

2 1