- ghc-devs - Haskell.org

Help Diagnosing 9.14.1 compiler "crash"
by Justin Bailey 05 Aug '26

05 Aug '26

All, Looking for some guidance on narrowing down an issue I am seeing at work. Some background: large monorepo, many packages; I'm on MacOS Tahoe (26.6). I have a problematic module that causes GHC to allocate a HUGE amount of memory under certain conditions. Compilation never finishes - instead, the process is killed by the OS. * With -O1, GHC consumes a huge amount of memory (> 32GB) before getting killed by the OS. * Without -O1, but with all available -f flags that seemed to be implied by -O1, GHC does NOT blow up and compilation succeeds. (List of flags below.) The last output (with -ddump-phases) in the failing case is always "*** Specialise [aaa.Tests.Service.Client.TestHelpers]:" followed by a newline, then nothing else. I'm working to isolate the code that's causing the problem, to get to a repro case, but in the meantime can anyone suggest why -O1 fails but all the -f flags do not? Thank you! p.s. I'm happy to share logs but don't want to spam the list if those aren't necessary. ********** Here are all the flags I used in place of -O1: -fblock-layout-cfg -fcall-arity -fcase-folding -fcase-merge -fcore-constant-folding -fcmm-control-flow -fcmm-elim-common-blocks -fcmm-sink -fcmm-static-pred -fcore-constant-folding -fcpr-anal -fcross-module-specialise -fcse -fenable-rewrite-rules -fexitification -ffloat-in -ffull-laziness -fignore-asserts -finline-generics -floopification -fnum-constant-folding -fsolve-constant-dicts -fspecialise -fstg-cse -fstrictness -funbox-small-strict-fields -fworker-wrapper ********** Here is the (possibly) relevant logs for compilation with -O1 that failed: *** Checking old interface for aaa.Tests.Service.Client.TestHelpers (use -ddump-hi-diffs for more details): [62 of 74] Compiling aaa.Tests.Service.Client.TestHelpers ( test/aaa/Tests/Service/Client/TestHelpers.hs, /Users/xxx.yyy/Source/health-engine/well-he-aaa/worktrees/master/dist-newstyle/build/aarch64-osx/ghc-9.14.1/aaa-service-client-0.0.0/t/test/noopt/build/test/test-tmp/aaa/Tests/Service/Client/TestHelpers.o, /Users/xxx.yyy/Source/health-engine/well-he-aaa/worktrees/master/dist-newstyle/build/aarch64-osx/ghc-9.14.1/aaa-service-client-0.0.0/t/test/noopt/build/test/test-tmp/aaa/Tests/Service/Client/TestHelpers.dyn_o ) *** Parser [aaa.Tests.Service.Client.TestHelpers]: !!! Parser [aaa.Tests.Service.Client.TestHelpers]: finished in 7.28 milliseconds, allocated 2.470 megabytes *** Renamer/typechecker [aaa.Tests.Service.Client.TestHelpers]: *** ConsistencyCheck [aaa.Tests.Service.Client.TestHelpers]: !!! ConsistencyCheck [aaa.Tests.Service.Client.TestHelpers]: finished in 1763.61 milliseconds, allocated 750.592 megabytes !!! Renamer/typechecker [aaa.Tests.Service.Client.TestHelpers]: finished in 2449.36 milliseconds, allocated 962.845 megabytes *** Desugar [aaa.Tests.Service.Client.TestHelpers]: Result size of Desugar (before optimization) = {terms: 713, types: 33,167, coercions: 15,521, joins: 0/171} Result size of Desugar (after optimization) = {terms: 551, types: 27,957, coercions: 15,828, joins: 0/93} !!! Desugar [aaa.Tests.Service.Client.TestHelpers]: finished in 5.46 milliseconds, allocated 2.524 megabytes *** Simplifier [aaa.Tests.Service.Client.TestHelpers]: Result size of Simplifier iteration=1 = {terms: 2,677, types: 74,181, coercions: 37,908, joins: 0/155} Result size of Simplifier iteration=2 = {terms: 1,737, types: 52,195, coercions: 27,615, joins: 0/88} Result size of Simplifier iteration=3 = {terms: 1,673, types: 51,005, coercions: 19,466, joins: 0/80} Result size of Simplifier iteration=4 = {terms: 1,630, types: 50,531, coercions: 19,333, joins: 0/78} Result size of Simplifier = {terms: 1,630, types: 50,531, coercions: 19,333, joins: 0/78} !!! Simplifier [aaa.Tests.Service.Client.TestHelpers]: finished in 217.38 milliseconds, allocated 120.723 megabytes *** Specialise [aaa.Tests.Service.Client.TestHelpers]: ********** Here are those same logs (up to specialisation) for a compilation that succeeded (no -O1, only the -f flags): *** Checking old interface for aaa.Tests.Service.Client.TestHelpers (use -ddump-hi-diffs for more details): [62 of 74] Compiling aaa.Tests.Service.Client.TestHelpers ( test/aaa/Tests/Service/Client/TestHelpers.hs, /Users/xxx.yyy/Source/health-engine/well-he-aaa/worktrees/master/dist-newstyle/build/aarch64-osx/ghc-9.14.1/aaa-service-client-0.0.0/t/test/noopt/build/test/test-tmp/aaa/Tests/Service/Client/TestHelpers.o, /Users/xxx.yyy/Source/health-engine/well-he-aaa/worktrees/master/dist-newstyle/build/aarch64-osx/ghc-9.14.1/aaa-service-client-0.0.0/t/test/noopt/build/test/test-tmp/aaa/Tests/Service/Client/TestHelpers.dyn_o ) *** Parser [aaa.Tests.Service.Client.TestHelpers]: !!! Parser [aaa.Tests.Service.Client.TestHelpers]: finished in 5.70 milliseconds, allocated 2.470 megabytes *** Renamer/typechecker [aaa.Tests.Service.Client.TestHelpers]: *** ConsistencyCheck [aaa.Tests.Service.Client.TestHelpers]: !!! ConsistencyCheck [aaa.Tests.Service.Client.TestHelpers]: finished in 1707.88 milliseconds, allocated 749.094 megabytes !!! Renamer/typechecker [aaa.Tests.Service.Client.TestHelpers]: finished in 2305.51 milliseconds, allocated 959.358 megabytes *** Desugar [aaa.Tests.Service.Client.TestHelpers]: Result size of Desugar (before optimization) = {terms: 713, types: 33,167, coercions: 15,521, joins: 0/171} Result size of Desugar (after optimization) = {terms: 551, types: 27,957, coercions: 15,828, joins: 0/93} !!! Desugar [aaa.Tests.Service.Client.TestHelpers]: finished in 4.66 milliseconds, allocated 2.526 megabytes *** Simplifier [aaa.Tests.Service.Client.TestHelpers]: Result size of Simplifier iteration=1 = {terms: 555, types: 27,953, coercions: 15,828, joins: 0/93} Result size of Simplifier = {terms: 555, types: 27,953, coercions: 15,828, joins: 0/93} !!! Simplifier [aaa.Tests.Service.Client.TestHelpers]: finished in 8.60 milliseconds, allocated 5.818 megabytes *** Specialise [aaa.Tests.Service.Client.TestHelpers]: Result size of Specialise = {terms: 555, types: 27,953, coercions: 15,828, joins: 0/10} !!! Specialise [aaa.Tests.Service.Client.TestHelpers]: finished in 3.98 milliseconds, allocated 2.227 megabytes

2 3

A shared statement on our environment in the face of LLMs
by Moritz Angermann 04 Aug '26

04 Aug '26

Dear friends, I've spent the last two days discussing the topic of LLM contributions in detail with Julian at length over video. As the discussion over the last few weeks have shown that it's very hard to find agreement on a common policy, we have tried to outline what we consider a statement that covers at least both of our views. With Julian and I representing a fairly wide spectrum of the positions, we hope that this may provide a statement that many can subscribe to. We have tried to keep it short, and not get distracted by specificies of workflows, quality standards, and definitions of terms, which seem to distract from the core that we want to address. Respectfully, Julian and Moritz ## A shared statement on our environment in the face of LLMs As human-LLM interaction is becoming more common, we find ourselves debating not only our technical goals, but also our understanding of open source community and values. This is why we all agree that we want to participate in an environment... 1. that inspires the exchange of technical ideas and knowledge between humans 2. that is supportive and accessible to the point that no one should feel the need to use LLM in the first place 3. that facilitates building trust relationships with one another 4. that rewards technical excellence and authenticity 5. that demands all interactions to be genuine and respectful We recognize that using LLMs responsibly is challenging. Not only can they be used for abuse[^1][^2], but they may also cause the quality of communication and intellectual engagement to decline[^3]. There is an emerging body of scientific literature supporting these concerns about negative effects on psychological, cognitive, real-world performance, etc. We recommend everyone to familiarize themselves with the current state of research. Here are a few links for your consideration. * [How AI Impacts Skill Formation](https://arxiv.org/abs/2601.20245) * [AI Assistance Reduces Persistence and Hurts Independent Performance](https://arxiv.org/abs/2604.04721) * [From Future of Work to Future of Workers: Addressing Asymptomatic AI Harms for Dignified Human-AI Interaction](https://arxiv.org/abs/2601.21920) * [AI Competency Erosion: Understanding Expertise Decay](https://link.springer.com/chapter/10.1007/978-3-032-11748-9_5) * [Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task](https://arxiv.org/abs/2506.08872) * [Investigating the Effects of LLM Use on Critical Thinking Under Time Constraints: Access Timing and Time Availability](https://arxiv.org/abs/2603.08849) _(This list does not claim to be comprehensive; it is merely meant to provide you with an initial stepping stone into the current research)._ Moreover we are especially concerned about their potential negative effects on open source communities[^4], human communication and collaboration. We strive to be an inclusive community and judge contributions on their merits. This includes the use of LLMs as long as it does not disturb our envisioned environment outlined earlier. We recognize that there are users and contributors of this project who would rather not interact with LLM generated content at all. To balance the preferences and self-determination of the diverse group of contributors, we require that the use of LLMs to generate content is clearly attributed as such, failure to do so may result in contributions to be rejected. We understand that this may not be satisfactory to everyone, since we cannot completely avoid exposure to LLM generated content. However, we will neither compromise our quality standards, nor allow any disruption of human-human interaction by the use of technology. Examples of inappropriate use are: - feeding someone's email into an LLM to generate an answer - creating automated LLMs written bug reports that a volunteer has to work through to determine if it has any value at all - generating large patches that take more time to review by the project than it took you to create We want this to be a project of human interaction, of shared curiosity and a beacon of engineering excellence. These are the shared values we stand by today as a project, and they may evolve along with our shared experiences and emerging scientific evidence over time. Julian Ospald Moritz Angermann -- [^1]: https://openai.com/index/disrupting-malicious-ai-uses/ [^2]: https://www.infoq.com/news/2026/02/ai-floods-close-projects/ [^3]: https://arxiv.org/abs/2506.06166 [^4]: https://arxiv.org/abs/2601.15494

6 11

Unable to create personal access token at gitlab.haskell.org
by Eric 03 Aug '26

03 Aug '26

Hi all, In order to fetch and checkout a branch of my fork of GHC, I am trying to create a personal access token which I would use as a password at the command line. However, when I try to add a new token, the page hangs displaying a the "please wait" circle graphic. Does anyone know what might be wrong? Regards, Eric

3 2

Re: LLM-generated code review as a service
by Simon Jakobi 03 Aug '26

03 Aug '26

Moritz, let me loop in the mailing list again. I understand that my service really doesn't have the value of a proper human code review. However, judging from my private trial runs, it does seem to catch bugs that neither the testsuite nor human reviewers caught. MR authors could of course use LLMs themselves to find the same bugs, but this doesn't seem to be widespread practice yet. Potential reasons for this: cost or lack of access for other reasons, insufficient quality of the review output. I also agree that there is a potential risk that my service could reduce the current human review practice. My suggestion would be to make a small survey in three months or so where we evaluate how my service affects this project, including the social interactions. Potential tweaks on how to use this service: * MR authors can request a private review for their draft MRs in order to catch issues before human reviewers spend time on them. * Only once the "human review" has concluded, we do a second GlaHiCo run, and the result is shared publicly on the MR. Does this sound better to you? Best, Simon Am Do., 30. Juli 2026 um 02:38 Uhr schrieb Moritz Angermann <moritz.angermann(a)gmail.com>: > > Hi Simon, > > I want to highlight the following: >> >> >> 1. The information in the review is intended for all people who are involved in an MR: Both authors and reviewers. > > > I personally find this to be straddling the line where we force exclusively LLM generated content on others and it starts to blur the line between where the human is. > > If a human receives (on request) a LLM review, treats it as probabilistic text output, and reviews the review for potential useful highlight, and then selectively makes those highlights their own before fixing them themselves or discussing them with others has a qualitatively difference to “look at the LLM generated review at <url>.” The latter one (at least to me), comes across as lacking respect towards others. > > If you use a tool to perform a review, I don’t really care, this is your agency, your freedom to do as you please, but if you pass this off to me as: here look at this output an llm generated, instead of reading the output making it your own and then passing it on as your own with your own comments, … who is it with whom I interact? > Why don’t I instead just ask the llm myself? > > > Now if everyone agrees that they want to collectively ask a llm, sure. Even though I do use LLMs, I wouldn’t want unedited llm output pass on to me. There is no value in that to me; I can do that myself. I want to interact with humans and their ideas, intellect and curiosity. > > It’s the same fundamental conflict I have wirh coderabbit and copilot reviews. I find them intellectually exceptionally boring. Distracting even. And having them in PR discussions (especially as comments like on GitHub), I feel myself losing interest extremely quickly. This is distinctly different from me using a LLM on the side as assertive tool to support my understanding, and form my opinion (and maybe word choice) when writing a comment. > > My primary concern is that while I’m perfectly ok with using LLMs, this opens the door towards verbatim llm output as a normalized way to interact with others; something which I oppose. > > Best, > Moritz > >> >> Am Mo., 27. Juli 2026 um 19:38 Uhr schrieb Simon Jakobi >> <simon.jakobi(a)gmail.com>: >> > >> > Hi devs! >> > >> > Inspired by the recent discussion on the LLM policy, I'd like to try >> > introducing LLM-generated code reviews in GHC, as an opt-in service. >> > >> > My motivation: >> > >> > * Catch issues before human reviewers spend time on them. >> > * Reduce the number of bugs merged. >> > >> > >> > What this is — and what it isn't >> > -------------------------------- >> > >> > This is tool output: requested on the MR, produced by a model, posted verbatim >> > and clearly marked as machine-generated. This is not a review in the sense of >> > draft LLM policy. >> > >> > I'm not vouching for any of it. Think of it as a linter the author could have >> > run themselves, except on my LLM budget. Nobody is required to act on >> > it even read it. >> > >> > I mention this explicitly because the policy asks reviewers to take full >> > responsibility for each line of their review. I can't do that here — it would >> > mean checking every finding myself, which defeats the purpose and would >> > restrict the service to areas of the compiler I already know well. >> > >> > >> > How to request one >> > ------------------ >> > >> > * Ping me on the MR with a comment like "@sjakobi llm-review please". >> > * Feel free to request particular aspects the review should cover. >> > * Authors can request a review for their own MRs. Maintainers can request one >> > on any MR. >> > * If I have enough usage left on my plan, I'll confirm that I'm on it. >> > * I'll then prompt the model, and post the result on the MR. >> > * Feedback on the quality of the review is of course very welcome. >> > >> > >> > What I promise >> > -------------- >> > >> > * Every review is labelled as machine-generated, with model, effort level and >> > the exact prompt used. >> > * Reviews are posted verbatim. I don't edit or curate them, so what you see is >> > exactly what the model produced. >> > * Only the public MR diff and public repository context go to the model. >> > Nothing else. >> > * I'll keep working on the prompts and the choice of model to improve the >> > signal-to-noise ratio. >> > * If the signal-to-noise ratio stays inacceptably bad, we can simply >> > stop this service. >> > >> > >> > Review coverage >> > --------------- >> > >> > I'll probably start with a fairly basic review prompt, primarily aimed at >> > correctness issues. >> > >> > Possible extensions: >> > >> > * Documentation consistency: check that documentation stays consistent, >> > including Notes elsewhere that reference the changed code. >> > * Performance: check for performance issues — potentially including checking >> > the -ddump-simpl output for the changed code for unnecessary >> > allocation etc. >> > * Feel free to suggest anything else! >> > >> > >> > Format >> > ------ >> > >> > Initially a single comment per review. Once we reach a good signal-to-noise >> > ratio, we can consider inline comments on the diff. >> > >> > >> > Caveats >> > ------- >> > >> > This is a volunteer service I intend to provide in my spare time. If I'm AFK >> > or on vacation, reviews will take longer. If I can't keep up with requests, I >> > will prioritise which MRs I run. I might take a break entirely. >> > >> > >> > Getting involved >> > ---------------- >> > >> > Is anyone interested in joining this effort? If so we could form a team >> > (@llm-reviewers?), and share prompting techniques, model choices, etc. >> > >> > If the service turns out to be genuinely useful, we can look into >> > automating it and – if necessary – possible funding. >> > >> > >> > Cheers, >> > Simon >> _______________________________________________ >> ghc-devs mailing list -- ghc-devs(a)haskell.org >> To unsubscribe send an email to ghc-devs-leave(a)haskell.org

2 2

GHC 9.12.5 RC3 is now available
by Magnus Viernickel 31 Jul '26

31 Jul '26

The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.12.5. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup. GHC 9.12.5 is a bug fix release. For a long form announcement, check out https://discourse.haskell.org/t/ghc-9-12-5-rc3-is-now-available/14491. This release candidate will have a two-week testing period. If all goes well the final release will be available the week of 13 August 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, please give this release a try and open a ticket if you see anything amiss. Best Magnus

1 0

GHC 9.14.2-rc1 is now available
by Zubin Duggal 31 Jul '26

31 Jul '26

The GHC developers are very pleased to announce the availability of the 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/). GHC 9.14.2 is a bug-fix release fixing many issues of a variety of severities and scopes, including: * Fixed a CorePrep miscompilation that could project a field out of an absent dictionary, resulting in a segfault (#25924) * Fixed demand analysis giving an absent demand to an argument that was still used by the function's stable unfolding, which could cause a run-time 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 NGG 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 sub-word widths * Fixed 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) * Fixed a stack alignment bug on x86 that could cause segfaults or corrupted registers when using AVX/AVX-512 vector code (#26595, #26822) * Fixed an "unknown/strange object" crash in the compacting garbage collector (#27434) * Fixed a regression that caused overloaded functions to no longer be specialised as effectively as in previous releases, hurting runtime performance (#26831) * Fixed exponential-time desugaring of nested `case` expressions (#27383, #20251) * Fixes for several compiler panics, including issues with SetLevels (#26681), the type-class specialiser (#26682), `mkTick` (#26772, #27121) and CoreToStg (#27182, #27386) * Fixed cast worker/wrapper incorrectly firing on INLINE functions (#26903) * Fixed negative type literals causing the compiler to hang (#26861) * Fixed associated type family and data family instance changes not triggering recompilation (#26183, #26705) * Improvements to determinism of compiler output, including the order in which `:info` lists instances (#26846, #26858, #26877, #27532) * Fixed split sections support on Windows (#26696, #26494) and the LLVM backend (#26770) * The JavaScript backend now supports more than 128 registers, fixing runtime `ReferenceError` failures for functions taking very many arguments (#26558) * Fixes for the Wasm backend, and the RISC-V and PowerPC native code generators * ... 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 13 August 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-rc1 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

2 1

LLM-generated code review as a service
by Simon Jakobi 30 Jul '26

30 Jul '26

Hi devs! Inspired by the recent discussion on the LLM policy, I'd like to try introducing LLM-generated code reviews in GHC, as an opt-in service. My motivation: * Catch issues before human reviewers spend time on them. * Reduce the number of bugs merged. What this is — and what it isn't -------------------------------- This is tool output: requested on the MR, produced by a model, posted verbatim and clearly marked as machine-generated. This is not a review in the sense of draft LLM policy. I'm not vouching for any of it. Think of it as a linter the author could have run themselves, except on my LLM budget. Nobody is required to act on it even read it. I mention this explicitly because the policy asks reviewers to take full responsibility for each line of their review. I can't do that here — it would mean checking every finding myself, which defeats the purpose and would restrict the service to areas of the compiler I already know well. How to request one ------------------ * Ping me on the MR with a comment like "@sjakobi llm-review please". * Feel free to request particular aspects the review should cover. * Authors can request a review for their own MRs. Maintainers can request one on any MR. * If I have enough usage left on my plan, I'll confirm that I'm on it. * I'll then prompt the model, and post the result on the MR. * Feedback on the quality of the review is of course very welcome. What I promise -------------- * Every review is labelled as machine-generated, with model, effort level and the exact prompt used. * Reviews are posted verbatim. I don't edit or curate them, so what you see is exactly what the model produced. * Only the public MR diff and public repository context go to the model. Nothing else. * I'll keep working on the prompts and the choice of model to improve the signal-to-noise ratio. * If the signal-to-noise ratio stays inacceptably bad, we can simply stop this service. Review coverage --------------- I'll probably start with a fairly basic review prompt, primarily aimed at correctness issues. Possible extensions: * Documentation consistency: check that documentation stays consistent, including Notes elsewhere that reference the changed code. * Performance: check for performance issues — potentially including checking the -ddump-simpl output for the changed code for unnecessary allocation etc. * Feel free to suggest anything else! Format ------ Initially a single comment per review. Once we reach a good signal-to-noise ratio, we can consider inline comments on the diff. Caveats ------- This is a volunteer service I intend to provide in my spare time. If I'm AFK or on vacation, reviews will take longer. If I can't keep up with requests, I will prioritise which MRs I run. I might take a break entirely. Getting involved ---------------- Is anyone interested in joining this effort? If so we could form a team (@llm-reviewers?), and share prompting techniques, model choices, etc. If the service turns out to be genuinely useful, we can look into automating it and – if necessary – possible funding. Cheers, Simon

9 20

GHC LLM policy take 2
by Simon Peyton Jones 29 Jul '26

29 Jul '26

Friends There has been a lot of discussion about GHC's LLM policy on this GHC thread <https://mailman.haskell.org/archives/list/ghc-devs@haskell.org/thread/ZTHFW…> . I have made quite few revisions in the light of this and other conversations. Here is the draft again <https://docs.google.com/document/d/1XxP8NXnbgr6faxXBXKw75zgoxIg-SzGv-Cvixyi…>, I hope in a close to final form. Any final thoughts? thanks Simon

22 77

How to use cachix to speed up GHC build process
by Eric Macaulay 27 Jul '26

27 Jul '26

Hello all, I am trying to get up and running building GHC on Nix. Can I ask: how can one use cachix to speed up the build process? (I tried looking at https://gitlab.haskell.org/ghc/ghc.nix#cachix but could not find any helpful information.) Regards, Eric Macaulay

2 1

Re: LLM policy for GHC
by Simon Jakobi 21 Jul '26

21 Jul '26

Hi Simon, here are my comments on the policy document: > In particular, you must not use AI-generated text in a direct conversation with a human reviewer. I think this is too restrictive. A contributor may easily reach the limits of their understanding during a code review, and I think it's ok to resort to using an LLM then. I think it's fair to require that they clearly mark the LLM-generated part of their response though. > P1: Write MRs that are easy to review I fully agree with this, and apologize that some of my MRs have not been easy to review! I do want to point out though that MRs marked as "Draft" should not be held to the same standards as a "ready" / non-draft MR. I frequently open draft MRs mainly to get the CI results. Sometimes I still get detailed reviews on these MRs, and then feel sorry that a reviewer wasted their time on this. > P2: Full responsibility > You must understand, and be able to explain, every line of code, and every sentence of documentation. Every line! I think that's a good goal, but even for MRs, maybe too strict a requirement. Where do you draw the line? Is the contributor expected to understand every (pre-existing) function they used? To what extent? Strictness and performance characteristics too? For bug reports, I think GHC should be more lenient, and instead require that LLM use is clearly signalled. > P3: Strong preference for human authorship > We strongly prefer human-written code I understand that it's "good exercise" to write code by hand. But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills. I already realize that some core contributors have much disdain for LLM-generated code. If the GHC project decides to devalue contributions of LLM-generated code with this language, I think this will reduce my motivation to contribute. > Writing it yourself forces you to think about every line; and it imposes a cost on you if you write 1000 lines instead of 100. IMHO contributing to GHC is already quite onerous and "costly", especially for newcomers. Just think of the flaky CI system and recent GitLab performance. Instead of trying to impose additional costs on contributors, I think it would be better to try to reduce the cost of reviewing and maintenance! For example, I think GHC should try using LLMs for "first-line" code review. LLMs are already very capable at debugging. How about investing in fuzzing or better automated testing, so bugs are discovered before they make it into a release? > We strongly prefer human-written documentation. Documentation generated by recentish models like Claude Opus 4.8 has indeed been quite bad. Claude Fable 5 is already much better at this. I think the main incentive resulting from this policy is to include _less_ documentation in contributions. In a world where LLMs are very capable of making sense of large code bases, maybe that's not much of a drawback. --- Overall, I feel that much of the recent discussion about LLMs in GHC and Haskell has been driven by fear and anger. I think many Haskellers are very proud of their skill to produce high-quality code, and as LLMs get better and better at this, this skill is becoming "less special". Instead of trying to discourage contributions that involve LLMs, I think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users. Sorry for the bad wording here and there. I did not use an LLM to write these comments, and it took me an embarrassingly long time. Cheers, Simon

18 67