- ghc-devs - Haskell.org

Notes/Commit messages/Comments - A new AI discussion
by Andreas Klebinger 24 Oct '26

24 Oct '26

Hello Devs, Given the use of AI has increased recently I think this deserves discussion. There are certain texts that are, ultimately, transient, or read less frequently as time moves on. This broadly includes tickets, which generally become mostly irrelevant once resolved. While reading AI tickets can be exhausting, I'm willing, within reason, to accept them as a fact of live. But there are parts of the code base in which we have prose that is written once and read often. I'm primarily concerned with Notes, Commit messages, and to a lesser degree code comments. I've noticed more people have been posting LLM generated bug fixes (fine, it's policy) where seemingly little work went into polishing texts other devs will read many times. I consider this a problem. I think it's important for certain parts of the code base to be written concisely. Something LLMs are terrible at today, and even skills make it marginally better. This is just a fact. I think especially with the release of Opus 5.5 this has become *more* of an issue as the prose is now only bad in a myriad ways that are not immediately obvious rather than being obviously atrocious at a glance. Which leads people to take it as-is without putting effort into writing it by hand, or at least trimming it down after the fact. This is obviously bad for human consumers of these texts. But even if you are "all in" on AI these texts are also objectively garbage for future AI use as they are bloated with irrelevant facts, meaningless past history, repeating things obvious from context and generally wordy for no benefit. They are simply bad. Is it fair to expect people to put in more effort into these? I think yes. Notes are *the* way to understand the code base. And making them worse permanently degrades the ability of newcomers to understand the codebase. Similarly commit messages are hugely important to be able to determine when changes where introduced, quickly find ranges of commits to bisect for new bugs and many more regular maintenance tasks. *My plan is to aggressively request improvement of prose during MR review going forward.* Accepting bad prose is worse for maintainers because they have to read texts three times to understand what is going on. It's worse for agents because it fills context windows with irrelevant facts and pointless trivia that poison their reasoning ability. It's just worse, and it takes little effort to fix. But maybe I'm alone in feeling this way. If everyone else is happy to read Opus text output all, or at least to have opus read opus output all day long. Then I will surrender this fight and move to another hill to die on. But if people are feeling similarly then please let me know and do likewise. I don't think it's a big ask either. If you are prompting already just type a draft in your commit message/note and let claude do formatting/typo/alignment fixes. A sloppy text pushed through claude will in most cases beat what any model today will generate on it's own. Maybe this changes in 2 years. But it's not changing today. It's not just a question of length. You can make a LLM generate shorter texts with a skill file or otherwise. But they are terrible at understanding what the tricky parts are, what is worth highlighting, what can be dropped because it is obvious from wider context. I think it's *easy* for every contributor who knows what is happening in their patch to reach a reasonable standard. But we have to ask them to do it and to set the expectation. And I hope we can do so. Andreas, freshly back from reading some claude output.

15 40

Replacing Hadrian with Buck2
by Simon Marlow 22 Oct '26

22 Oct '26

As I mentioned to a few people recently, I wanted to explore replacing Hadrian with Buck2. I've got a prototype to the point where it can build the stage2 compiler and all the libraries on Linux: > buck2 run :stage2-ghc -- --interactive GHCi, version 10.1.20261017: https://www.haskell.org/ghc/ :? for help Using default language edition: GHC2024 ghci> 1+2 3 ghci> This includes dynamic/static, all the RTS ways and profiling is allegedly working although I haven't tested it very much. It's a LOT smaller than Hadrian - hard to say exactly how much because some of the code is in the shared projects cabal-buck2 and haskell-buck2, but there's about 1400 lines of Buck2 stuff in the ghc repo and nothing in the library submodules. I've written up the design along with some notes on how to set it up and try it over here: https://github.com/simonmar/ghc/blob/buck2/README.buck2.md Keen to hear what people think about this. Are there key metrics that we should measure to understand whether it's better than Hadrian? What are the workflow aspects that people find slow currently? Cheers Simon

11 26

Windows failure with annotations
by Facundo Domínguez 07 Oct '26

07 Oct '26

Dear devs, I'm a tad puzzled with a test failure on a MR [1] I'm preparing to allow annotations in simple interfaces (e.g. those produced by haddock). Before I debug this further, I would like to check the basics with someone more familiar with GHC on Windows, if possible. The failing test checks that simple interfaces do have annotations, and this test is part of my contribution. The annotations are simply missing on windows. This test passes on all other platforms. I looked for conditional compilation that could affect this, but haven't spotted anything relevant yet. Other plugin and annotation tests seem to run fine on Windows. The change itself only modifies two lines of code, which I paste below for convenience. Any conjectures are welcome. Best, Facundo [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/16754 diff --git a/compiler/GHC/Iface/Tidy.hs b/compiler/GHC/Iface/Tidy.hs index b3537514ac4a..2ddde284c2be 100644 --- a/compiler/GHC/Iface/Tidy.hs +++ b/compiler/GHC/Iface/Tidy.hs @@ -172,7 +172,8 @@ mkBootModDetailsTc logger tcg_fam_insts = fam_insts, tcg_complete_matches = complete_matches, tcg_mod = this_mod, - tcg_default_exports = default_exports + tcg_default_exports = default_exports, + tcg_anns = anns } = -- This timing isn't terribly useful since the result isn't forced, but -- the message is useful to locating oneself in the compilation process. @@ -184,7 +185,7 @@ mkBootModDetailsTc logger , md_insts = insts' , md_fam_insts = fam_insts , md_rules = [] - , md_anns = [] + , md_anns = anns , md_exports = exports , md_complete_matches = complete_matches }) -- All views and opinions expressed in this email message are the author's personal opinions and do not represent those of the organization or its customers.

2 1

GitLab stalling
by Simon Peyton Jones 07 Oct '26

07 Oct '26

I'm getting a lot of messages like the one below. Sometimes pressing submit repeatedly makes it work, sometimes not. Is GitLab struggling today? Simon [image: image.png]

2 1

Very very slow Hadrian
by Simon Peyton Jones 28 Sep '26

28 Sep '26

Friends Is it my imagination or has Hadrian become a LOT slower? I am trying to run a single test, thus: hadrian/build -j6 \ --flavour=perf+no_profiled_libs+ticky_ghc \ test \ --skip=_build/stage0/** \ --skip=_build/stage1/** \ --skip=_build/stage1/rts/** \ --skip=_build/stage1/libraries/** \ --skip=_build/stage1/utils/** \ --docs=none \ --only=ClassOperator This takes 70 seconds, of which almost all is spent with Hadrian saying stuff below *Something must be wrong! * Seventy seconds to run one test! Then to accept the new output is another 70 seconds. If I have a couple of dozen test-output wibbles to fix, that adds up to a lot of time. Simon ]0;Starting...(/home/simonpj/code/HEAD-31) ]0;Running for 5s [119/38037], predicted 264m08s (0%)(/home/simonpj/code/HEAD-31) ]0;Running for 10s [8853/38038], predicted 36m59s (0%)(/home/simonpj/code/HEAD-31) ]0;Running for 15s [12109/38038], predicted 9m46s (2%)(/home/simonpj/code/HEAD-31) ]0;Running for 20s [13119/38038], predicted 7m03s (4%)(/home/simonpj/code/HEAD-31) ]0;Running for 25s [13879/38038], predicted 7m19s (5%)(/home/simonpj/code/HEAD-31) ]0;Running for 30s [14485/38038], predicted 6m58s (6%)(/home/simonpj/code/HEAD-31) ]0;Running for 35s [15338/38038], predicted 6m06s (8%)(/home/simonpj/code/HEAD-31) ]0;Running for 40s [16434/38038], predicted 2m56s (17%)(/home/simonpj/code/HEAD-31) ]0;Running for 45s [20588/38038], predicted 3m32s (16%)(/home/simonpj/code/HEAD-31) ]0;Running for 50s [26354/38038], predicted 63m21s (1%)(/home/simonpj/code/HEAD-31) ]0;Running for 55s [30040/38038], predicted 49m36s (1%)(/home/simonpj/code/HEAD-31) ]0;Running for 1m00s [35123/38038], predicted 19m59s (4%)(/home/simonpj/code/HEAD-31) # ghc

3 2

Currently no native x86_64 darwin runner
by Magnus Viernickel 25 Sep '26

25 Sep '26

Dear GHC Devs, Alpha, our beloved native x86_64 darwin (MacOS) runner has perished. From my perspective, this is final since I cannot touch the system and all remote trouble shooting seems to point me at its demise. A potential touching of the system of a third party may make it come back. The only workflow affected is test-primops x86_64 darwin. I have switched that to use emulation via rosetta for now (run on our aarch64-darwin runners). If you think this is a bad idea, please contact me. There also was a few minutes of downtime yesterday and today because I applied a critical security patch to gitlab. (path traversal vulnerability, aka ../) Best Magnus

1 0

GHC 10.0.1-alpha1 is now available
by Zubin Duggal 20 Sep '26

20 Sep '26

The GHC developers are very pleased to announce the availability of the first alpha prerelease of GHC 10.0.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][] and via [GHCup](https://www.haskell.org/ghcup/). GHC 10.0 will bring a number of new features and improvements, including: * The default language edition is now `GHC2024` ([GHC Proposal #632][ghc2024], #26039). * `Type` and `Constraint` are now completely distinct types, just as much as `Int` and `Bool` (#24279). * The new [QualifiedStrings][] language extension ([GHC Proposal #723][qualified-strings]) allows string literals to be qualified using module qualification syntax, so that `M."my string"` desugars to`M.fromString "my string"`. * The treatment of static forms has been simplified, implementing [GHC Proposal #732][static-forms] (#26556). The free term variables of `(static e)` must now be bound at top level. * `-fpolymorphic-specialisation` is now (re)enabled by default (#23559), * Bytecode can now be written to disk with `-fwrite-byte-code` and packaged into bytecode libraries with `-bytecodelib`, which the interpreter can use to satisfy package dependencies (#26298). * Executables can now be properly statically linked with the new `-fully-static` and `-static-external` flags (#26434). * SIMD support in the AArch64 native code generator (#26536). * A new `poll` I/O manager, which is now the default in the single-threaded RTS on all POSIX platforms except macOS (!9677). * Version 2 of the [GHC Jobserver Protocol][jsem] for GHC's `-jsem` jobserver on Linux and other POSIX platforms (#25087, #27253). This is sadly a necessary breaking change. `-jsem` requires cabal-install 3.18 or later, and is otherwise ignored with a warning, falling back to sequential compilation. * Changes to `base`: * `GHC.Num.{BigNat,Integer,Natural}` are no longer exposed ([CLC #359][clc-359]) and GHC internals in `GHC.Num` are deprecated ([CLC #360][clc-360]). * `Data.List.init` and `Data.List.last` now carry an `x-partial` warning ([CLC #292][clc-292]). * The minimum bootstrap compiler is now GHC 9.10, LLVM versions up to 23 are supported (#26813, #27764), and the Debian 9, Debian 10, Ubuntu 18.04 and Ubuntu 20.04 bindists have been dropped in favour of a new Debian 13 bindist (#25876). * ... and many more A full accounting of changes can be found in the [release notes][]. See the [migration guide][] for guidance on migrating programs to this release. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. Given the many changes in this major release, we would very much appreciate testing on downstream workloads. 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. [downloads.haskell.org] https://downloads.haskell.org/ghc/10.0.1-alpha1 [release notes]: https://downloads.haskell.org/ghc/10.0.1-alpha1/docs/users_guide/10.0.1-not… [migration guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/10.0 [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [ghc2024]: https://github.com/ghc-proposals/ghc-proposals/pull/632 [static-forms]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0732-s… [QualifiedStrings]: https://downloads.haskell.org/ghc/10.0.1-alpha1/docs/users_guide/exts/quali… [qualified-strings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0723-q… [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-j… [clc-292]: https://github.com/haskell/core-libraries-committee/issues/292 [clc-359]: https://github.com/haskell/core-libraries-committee/issues/359 [clc-360]: https://github.com/haskell/core-libraries-committee/issues/360

2 1

GHC 9.14.2-rc2 is now available
by Zubin Duggal 17 Sep '26

17 Sep '26

The GHC developers are very pleased to announce the availability of the second release candidate for GHC 9.14.2. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][] and via [GHCup](https://www.haskell.org/ghcup/). See also the [previous announcement of 9.14.2-rc1][rc1]. The changes since the first release candidate are: * Several fixes to the specialiser and demand analyser for miscompilations causing incorrect runtime results, crashes, or hangs (#27626, #27627, #27629, #27703, #27704, #27705, #27717). * Fixes for a number of runtime system bugs: * a missing memory barrier in the parallel garbage collector, which could crash or silently corrupt the heap on weakly-ordered architectures such as AArch64 (#27477). * a use-after-free with TSOs (#26716, #26717). * an "unknown/strange object" crash in the compacting collector when collecting the large data constructors that the bytecode interpreter allocates (#27649). * a segfault when querying the label of an unlabelled thread (#27618). * a crash when capturing or resuming a delimited continuation that adjusts the asynchronous exception masking state (#27651). * stack corruption when returning large unboxed tuples in GHCi (#27633). * Further fixes to the AArch64 native code generator, addressing bugs that caused incorrect runtime results from subword operations (#27430, #27533, #27537, #27538, #27539, #27550). * `toException` for `SomeException` no longer drops the attached `ExceptionContext`, and a `catchSTM` handler no longer breaks `retry` or asynchronous exception delivery (#27455, #27657). * Reduced memory usage with multiple home units (#26423, #27308, #27500, #27748). * Fixes for panics and spurious out-of-scope errors involving type arguments in pattern synonym right-hand sides (#27440, #27583, #27586). * The pattern-match checker now recognises `considerAccessible` under ticks, and no longer emits a spurious `-Wincomplete-uni-patterns` warning under `-finfo-table-map` (#27314, #27360). * The deprecation warning for static forms, added in rc1, no longer fires on free type variables (#27664). * A fix for a regression preventing modules from being loaded into GHCi after startup (#27202, #27640). * A fix for representation-polymorphism checks producing a coercion that fails Core Lint (#27639). * Support for LLVM up to version 23 (#27764). * Updates for libffi (3.8.0), `directory` (1.3.11.0), `file-io` (0.1.6), `haskeline` (0.8.5.0) and `os-string` (2.0.10). GHC 9.14.2 is a bug-fix release fixing many issues of a variety of severities and scopes, including: * Version 2 of the [GHC Jobserver Protocol][jsem] for GHC's `-jsem` jobserver on Linux and other POSIX platforms (#25087, #27253). This is sadly a necessary breaking change: `-jsem` requires cabal-install 3.18 or later, and is otherwise ignored with a [warning][jsem-warning], falling back to sequential compilation. * A new deprecation warning for static forms that mention nested let-bound variables. This will become an error in GHC 10.0 ([GHC Proposal #732][static-forms], #26718). * A fix for a CorePrep miscompilation that could project a field out of an absent dictionary, resulting in a segfault (#25924). * A fix for demand analysis giving an absent demand to an argument that was still used by the function's stable unfolding, which could cause a runtime crash (#26416). * Numerous fixes for register allocation and Cmm register-conflict analysis bugs, preventing incorrect code generation and corruption of vector registers when spilling and reloading (#26411, #26526, #26537, #26542, #26550, #26668). * Many NCG fixes on AArch64: `MOVK` clobbering live values (#26980), register clobbering and an incorrect overflow bit in `MUL2` (#27046, #27047), and incorrect sign extension (#26978) and unsigned right shift (#26979) at subword widths. * A fix for a stack alignment bug on x86 that could cause segfaults or corrupted registers when using AVX/AVX-512 vector code (#26595, #26822). * Fixes for several black hole handling bugs that could lead to deadlocks or crashes in multithreaded programs, showing up as hangs or "END_TSO_QUEUE object entered" errors (#26922, #26936). * Fixes for many other runtime system crashes and races (#26341, #26573, #26640, #27007, #27008, #27009, #27082). * A fix for an "unknown/strange object" crash in the compacting garbage collector (#27434). * Fixes for split sections on Windows (#26696, #26494) and the LLVM backend (#26770). * Fixes for the Wasm backend (#26916, #27257), and the RISC-V (#27300, #27303, #27306) and PowerPC (#23969, #24145, #26828) native code generators. * The JavaScript backend now supports more than 128 registers, fixing runtime `ReferenceError` failures for functions taking very many arguments (#26558). * Correctness and performance improvements in the bytecode interpreter (#12953, #26287, #26946, #26995, #27001). * Fixes for several compiler panics, including issues with SetLevels (#26681), the type-class specialiser (#26682), `mkTick` (#26772, #27121), CoreToStg (#27182, #27386), the pattern-match checker (#25926, #27124), module graph reachability (#26568), and continuation trimming for bottoming functions (#27261). * Fixes for several cases where the compiler could hang or loop, including with negative type literals (#26861), deep subsumption (#26823), and when simplifying the right-hand sides of rewrite rules (#26323, #26826). * A fix for cast worker/wrapper incorrectly firing on INLINE functions (#26903). * A fix for exponential-time desugaring of nested `case` expressions (#27383, #20251). * A fix for a regression that caused overloaded functions to no longer be specialised as effectively as in previous releases, hurting runtime performance (#26831). * A fix for associated type family and data family instance changes not triggering recompilation (#26183, #26705). * Fixes for Explicit Level Imports and Template Haskell staging (#26088, #26098, #26099, #26616, #27385). * Improvements to determinism of compiler output, including the order in which `:info` lists instances (#26846, #26858, #26877, #27532). * Additions for GHCi and GHC API users: the `-fimport-loaded-targets` flag (#26866), custom external interpreter commands (#26652), `decodeStackWithIpe` and related stack-decoding helpers (#27065), an optional `SrcLoc` on `StackAnnotation` (#26806), and a `gc_sync_elapsed_ns` counter in `RTSStats` (#26944). * ... 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 1 October 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.14/docs/users_guide/9.14.2-… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.14.2-rc2 [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-j… [static-forms]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0732-s… [jsem-warning]: https://downloads.haskell.org/ghc/9.14.2-rc2/docs/users_guide/using-warning… [rc1]: https://www.haskell.org/ghc/blog/20260730-ghc-9.14.2-rc1-released.html [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

short downtime to revert a bug in gitlab-registry
by Magnus Viernickel 15 Sep '26

15 Sep '26

Dear GHC Devs, looks like we pulled in a bug when I recently updated gitlab for security reasons. I hope to revert it, which will cause a few minutes of downtime. Best Magnus

1 1

Re: GHC LLM policy vs copyright
by Carter Schonwald 15 Sep '26

15 Sep '26

yes, because code is math, and sometimes theres only one proof, and copyright doesnt protect factual stuff just the ultra soecific exact sentence (except when its literally the only sane way to say soemthing). there is a huge amount of law / case law / history for how this works, and fortunately literally here means verbatim naively these two remarks sound contradictory, but its really a reflection of the anthropogenic complexity of humanity On Tue, Sep 1, 2026 at 1:56 PM <code(a)jaro.addy.io> wrote: > If you define “exact literal content” so broadly as to allow for > translations > of prose, why wouldn't it also apply to translating software to different > languages or using different naming conventions and other minor code style > elements? > > On 9/1/26 19:50, Carter Schonwald 'carter.schonwald at gmail.com' wrote: > > translations are explicitly reusing the exact literal content, and > theres > > explicitly carve outs in modern law around translated works > > > > > > math and food recipes are explicitly not protected by copyright law. > > > > i hope that helps clarify? > > > > On Tue, Sep 1, 2026 at 1:41 PM <code(a)jaro.addy.io <mailto: > code(a)jaro.addy.io>> > > wrote: > > > > > building dimilar code for a similar task in a > > > different language is definitely not infringing unless its also > copying > > all > > > the text from the source application like some sort of text rpg. > > What if we compare this to literature? Surely a translation of a > book into > > another language is still considered a derivative work, even if it > reuses none > > of the “literal text”. > > > > >

3 3