August 2026 - ghc-devs

ghc handbook
by Sasha Bogicevic 09 Aug '26

09 Aug '26

Hey all, I wanted to share ghc handbook I made using AI https://devnull-org.github.io/ghc-handbook/ I know people have opposite views when it comes to AI usage but I believe using AI to learn things is really poweful. This page might help interested haskell programmers to explore ghc internals. Not sure how useful it is for people already knowledgable about ghc but at least the ghc notes are easy to access. Anyway, hope this attracts new people to do some work on the compiler, please let me know what you think or if anybody is interested in reviewing the content. This is just the first draft so future versions should be better. Thanks, Sasha PGP 6023d9e35e208decad5101f0be284d15ea8108a2 Sent from Proton Mail for iOS.

4 6

report from the gitlab front
by Magnus Viernickel 06 Aug '26

06 Aug '26

Dear GHC Devs, I have some interesting information to share with you. You might have noticed that our gitlab was a bit more swamped the recent days again and today I investigated and discovered that Anubis was getting bypassed by requests with a new user agent that I haven't seen before, "Lightpanda/1.0". Normally, anubis checks for user agents that are known bot user agents and blocks them; Lightpanda was left unblocked because Anubis only filtered for LightPanda (capital p). This is normally not a problem because most crawlers try to use user agents that look like browsers; if you're using a browser user agent, you're getting a higher weight and you get presented as challenge; but you're also much harder to sift out because you look benign. While the amount of requests we were getting with that user agent had reached absurd dimensions, this was also a blessing. First of all, it was easy to ban it and reduce the gitlab load drastically. Second, now we could run an analysis on who is using these malicious clients. Xe, the creator of Anubis kindly provided me with a tool that qualitatively (based on unique IP addresses, disregarding hits per IP) puts IP addresses in buckets based on several known factors, e.g. location or the ASN (which entity the IP address block is delegated to). The results can be seen here: https://gitlab.haskell.org/-/snippets/6132 A few noteworthy things: - 1.4 Million distinct IPv4 addresses have been used with this bot user agent - the IP addresses stem from 225 different countries. I think we have ~ 30 more distinct ISO country codes. - we have some known faces! like spacex which got flagged 100% time on their 21000 distinct IP addresses they're using to DDoS us - we also have quite a lot of domestic use ASNs, which indicates that botnets are involved, too! - Xe noted, that we can proudly say this counts as a DDoS Mind that this does not include all the spammers that are actually trying to hide the fact that they're spammers, which still exist. Also mind that this was just the data from ~1 day of logs. I hope this gives a nice sense of what we're dealing with and maybe it also helps with your frustration to see my frustration and the fact that we're sometimes getting little wins. Like today. Best Magnus

3 2

CI issue resolved
by Magnus Viernickel 06 Aug '26

06 Aug '26

Hi GHC Devs, we had CI failing this morning pretty badly. This issue should be resolved. Please excuse the troubles; you may restart your CI runs. If you have issue with any CI runner, please contact me. Best Magnus

1 0

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