- ghc-devs - Haskell.org

Proposal: Roundtrip serialization of Cmm (parser-compatible pretty-printer output)
by Diego Antonio Rosario Palomino 28 Jul '25

28 Jul '25

Hello GHC devs, I'm currently working on Cmm documentation and tooling improvements as part of my Google Summer of Code project. One of my core goals is to make Cmm roundtrip serializable. Right now, the in-memory Cmm data structure—generated programmatically (e.g., from STG via GHC)—can be pretty-printed, and Cmm can also be parsed. However, the pretty-printed version is not compatible with the parser. That is, we cannot take the output of the pretty printer and feed it directly back into the parser. Example: Parseable version: sum { cr: bits64 x; x = R1 + R2; R1 = x; jump %ENTRY_CODE(Sp(0))[R1]; } Pretty-printed version: sum() { // [] { info_tbls: [] stack_info: arg_space: 8 } {offset cf: // global _ce::I64 = R1 + R2; R1 = _ce::I64; call (I64[Sp + 0 * 8])(R1) args: 8, res: 0, upd: 8; } } Another example: Parseable version: simple_sum_4 { // [R2, R1] cr: // global bits64 _cq; _cq = R2; bits64 _cp; _cp = R1; R1 = _cq + _cp; jump (bits64[Sp])[R1]; } Pretty-printed version: simple_sum_4() { // [] { info_tbls: [] stack_info: arg_space: 8 } {offset cs: // global _cq::I64 = R2; _cr::I64 = R1; R1 = _cq::I64 + _cr::I64; call (I64[Sp])(R1) args: 8, res: 0, upd: 8; } } While it’s possible to write parseable Cmm that resembles the pretty-printed version (and hence the internal ADT), they don’t fully match—mainly because the parser inserts inferred fields using convenience functions. Proposal: To make roundtrip serialization possible, I propose supporting a new syntax that matches the pretty printer output exactly. There are a couple of design options: 1. Create a separate parser that accepts the pretty-printed syntax. Files could then use either the current parser or the new strict one. 2. Extend the current parser with a dedicated block syntax like: low_level_unwrapped { ... } This second option is the one my mentor recommends, as it may better reflect GHC developers' preferences. In this mode, the parser would not insert any inferred data and would expect the input to match the pretty-printed form exactly. This would enable a true roundtrip: - Compile Haskell to Cmm (in-memory AST) - Pretty-print and write it to disk (wrapped in low_level_unwrapped { ... }) - Later read it back using the parser and continue with codegen Optional future direction: As a side note: currently the parser has both a “high-level” and a “low-level” mode. The low-level mode resembles the AST more closely but still inserts some inferred data. If we introduce this new “exact” low-level form, it's possible the existing low-level mode could become redundant. We might then have: - High-level syntax - New low-level (exact) - And possibly deprecate the current low-level variant I’d be interested in your thoughts on whether that direction makes sense. Serialization libraries? One technically possible—but likely unacceptable—alternative would be to derive serialization via a library like aeson. That would enable serializing and deserializing the Cmm AST directly. However, I understand that aeson adds a large dependency footprint, and likely wouldn't be suitable for inclusion in GHC. Final question: Lastly—I’ve heard that parts of the Cmm pipeline may currently be under refactoring. If that’s the case, could you point me to which parts (parser, pretty printer, internal representation, etc.) are being modified? I’d like to align my efforts accordingly and avoid conflicts. Thanks very much for your time and input! I'm happy to iterate on this based on your feedback. Best regards, Diego Antonio Rosario Palomino GSoC 2025 – Cmm Documentation & Tooling

4 3

Correct parsers for bounded integral values
by Stefan Klinger 22 Jul '25

22 Jul '25

Hello, I'd like to bring to your attention a discussion that I have started over at Haskell-cafe [1]. I was complaining about the silent overflow of parsers for bounded integers: > read "298" :: Word8 42 I find this unsatisfying, and I have demonstrated a solution [2] that seems correct and performant. To avoid cross posting, I'd rather point you to the discussion on the Haskell-cafe mailing list [1]. I would like to help get this into GHC and also other parsing libraries. Not all libraries suffer from this issue, but some do, including GHC and its `base` package. How can I attempt this? Should I file a bug report? Or try to follow the instructions at ghc.dev [3] and submit a pull request? I would start tinkering at [this point][4] as soon as I manage to compile GHC. Would you want to share any advice beforehand? I'd really appreciate to be stopped before wasting effort ;-) Also, I probably only can work on this on weekends. Cheers Stefan [1]: https://mail.haskell.org/pipermail/haskell-cafe/2025-July/137134.html [2]: https://github.com/s5k6/robust-int [3]: https://ghc.dev/ [4]: https://hackage.haskell.org/package/ghc-internal-9.1201.0/docs/src/GHC.Inte… -- Stefan Klinger, Ph.D. -- computer scientist o/X http://stefan-klinger.de /\/ https://github.com/s5k6 \ I prefer receiving plain text messages, not exceeding 32kB.

5 6

GHC 9.14.1 release status
by Ben Gamari 22 Jul '25

22 Jul '25

Hi all, Last week GHC 9.14 officially forked. Over the past week I have been working to get the branch into a releasable state. Unfortunately, there are currently issues with the Windows release target that which are preventing preparation of the first alpha. I hope to have this resolved by the end of this week, allowing our first pre-release in the middle of next week. Ultimately, it is not unlikely that the release schedule will slip a bit as a result of these Windows issues. We will keep the lists informed as the situation develops. Cheers, - Ben

1 0

Improving the GHC proposals process
by Matthew Pickering 18 Jul '25

18 Jul '25

Hi all, It seems to me that the general opinion is that GHC developers are reluctant to take part in the GHC proposals process. This is an unfortunate state of affairs, the proposals process should be one serving developers rather than a hindrance. Therefore I have started a discussion on the ghc-proposals issue tracker about some ways which it might be made better. https://github.com/ghc-proposals/ghc-proposals/issues/706 Please leave your thoughts there, on how you feel about the process in general or concretely about the suggestions I have made. Cheers, Matt

1 0

GHC LTS Releases
by Andreas Klebinger 15 Jul '25

15 Jul '25

I'm pleased to announce LTS plans for GHC Read all the details here: https://www.haskell.org/ghc/blog/20250702-ghc-release-schedules.html There is also a discourse thread if you have feedback: https://discourse.haskell.org/t/ghc-lts-releases-the-glasgow-haskell-compil… Best Wishes Andreas

1 0

Reproducing a build failure
by Simon Peyton Jones 11 Jul '25

11 Jul '25

Friends In !14410, specifically on Fedora, I get this build failure <https://gitlab.haskell.org/ghc/ghc/-/jobs/2225860>. Some kind of crash in some invocation of Haddock to make the docs for ghc-internal. Question: how can I reproduce this failure on my own machine? It builds fine for me. Thanks Simon Error when running Shake build system: at want, called at src/Main.hs:127:44 in main:Main * Depends on: binary-dist at need, called at src/Rules/BinaryDist.hs:311:13 in main:Rules.BinaryDist * Depends on: binary-dist-dir at need, called at src/Rules/BinaryDist.hs:168:9 in main:Rules.BinaryDist * Depends on: docs at need, called at src/Rules/Documentation.hs:137:9 in main:Rules.Documentation * Depends on: _build/doc/html/index.html at need, called at src/Rules/Documentation.hs:214:9 in main:Rules.Documentation * Depends on: _build/doc/html/libraries/index.html at need, called at src/Rules/Documentation.hs:251:9 in main:Rules.Documentation * Depends on: _build/doc/html/libraries/ghc-internal-9.1400.0-9f99/ghc-internal.haddock at cmd, called at src/Builder.hs:404:5 in main:Builder * Raised the exception: Development.Shake.cmd, system command failed Command line: _build/stage1/bin/haddock --verbosity=0 -B_build/stage1/lib --lib=_build/stage1/lib --odir=_build/doc/html/libraries/ghc-internal-9.1400.0-9f99 --dump-interface=_build/doc/html/libraries/ghc-internal-9.1400.0-9f99/ghc-internal.haddock --html '--title=ghc-internal-9.1400.0: Basic libraries' --prologue=_build/doc/html/libraries/ghc-internal-9.1400.0-9f99/haddock-prologue.txt --optghc=-D__HADDOCK_VERSION__=2300 --hide=GHC.Internal.Data.Typeable.Internal --hide=GHC.Internal.IO.Handle.Lock.Common --hide=GHC.Internal.IO.Handle.Lock.Flock --hide=GHC.Internal.IO.Handle.Lock.LinuxOFD --hide=GHC.Internal.IO.Handle.Lock.NoOp --hide=GHC.Internal.IO.Handle.Lock.Windows --hide=GHC.Internal.StaticPtr.Internal --hide=GHC.Internal.Event.Arr --hide=GHC.Internal.Event.Array --hide=GHC.Internal.Event.Internal --hide=GHC.Internal.Event.Internal.Types --hide=GHC.Internal.Event.IntTable --hide=GHC.Internal.Event.IntVar --hide=GHC.Internal.Event.PSQ --hide=GHC.Internal.Event.Unique --hide=GHC.Internal.Unicode.Bits --hide=GHC.Internal.Unicode.Char.DerivedCoreProperties --hide=GHC.Internal.Unicode.Char.UnicodeData.GeneralCategory --hide=GHC.Internal.Unicode.Char.UnicodeData.SimpleLowerCaseMapping --hide=GHC.Internal.Unicode.Char.UnicodeData.SimpleTitleCaseMapping --hide=GHC.Internal.Unicode.Char.UnicodeData.SimpleUpperCaseMapping --hide=GHC.Internal.Unicode.Version --hide=GHC.Internal.System.Environment.ExecutablePath --hide=GHC.Internal.Bignum.Backend.GMP --hide=GHC.Internal.Event.Control --hide=GHC.Internal.Event.EPoll --hide=GHC.Internal.Event.KQueue --hide=GHC.Internal.Event.Manager --hide=GHC.Internal.Event.Poll --hide=GHC.Internal.Event.Thread --hide=GHC.Internal.Event.TimerManager --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-hide-all-packages --optghc=-no-user-package-db '--optghc=-package-env -' '--optghc=-this-unit-id ghc-internal-9.1400.0-9f99' '--optghc=-this-package-name ghc-internal' '--optghc=-package-id rts-1.0.3' --optghc=-i --optghc=-i/builds/ghc/ghc/_build/stage1/libraries/ghc-internal/build --optghc=-i/builds/ghc/ghc/_build/stage1/libraries/ghc-internal/build/autogen --optghc=-i/builds/ghc/ghc/libraries/ghc-internal/src --optghc=-Irts/include --optghc=-I_build/stage1/libraries/ghc-internal/build --optghc=-I_build/stage1/libraries/ghc-internal/build/include --optghc=-Ilibraries/ghc-internal/include --optghc=-I/builds/ghc/ghc/rts/include --optghc=-I/builds/ghc/ghc/_build/stage1/rts/build/include --optghc=-optP-include --optghc=-optP_build/stage1/libraries/ghc-internal/build/autogen/cabal_macros.h --optghc=-optP-DBIGNUM_GMP --optghc=-outputdir --optghc=_build/stage1/libraries/ghc-internal/build --optghc=-this-unit-id --optghc=ghc-internal --optghc=-Wcompat --optghc=-Wnoncanonical-monad-instances --optghc=-XHaskell2010 --optghc=-XNoImplicitPrelude --optghc=-no-global-package-db --optghc=-package-db=/builds/ghc/ghc/_build/stage1/inplace/package.conf.d --optghc=-ghcversion-file=rts/include/ghcversion.h --optghc=-ghcversion-file=rts/include/ghcversion.h --optghc=-this-unit-id --optghc=ghc-internal --optghc=-Wcompat --optghc=-Wnoncanonical-monad-instances --optghc=-XHaskell2010 --optghc=-XNoImplicitPrelude --optghc=-no-global-package-db --optghc=-package-db=/builds/ghc/ghc/_build/stage1/inplace/package.conf.d --optghc=-ghcversion-file=rts/include/ghcversion.h --optghc=-ghcversion-file=rts/include/ghcversion.h --optghc=-Wno-deprecated-flags --optghc=-Wno-trustworthy-safe +RTS -t_build/stage1/haddock-timing-files/ghc-internal.t --machine-readable -RTS --hyperlinked-source --hoogle --quickjump @/tmp/extra-file-54706448418404-4067-11690 Exit code: 1 Stderr: <no location info>: error: panic! (the 'impossible' happened) GHC version 9.14.0.20250710: idDetails a_alNe Call stack: CallStack (from HasCallStack): pprPanic, called at compiler/GHC/Types/Var.hs:1079:43 in ghc-9.14.0.20250710-7d78:GHC.Types.Var

1 0

openFile gives "file is locked" error on Linux when creating a non-existing file
by Harendra Kumar 07 Jul '25

07 Jul '25

Hi everyone, We have a long standing, elusive and intermittent test failure in streamly's file system event test suite. The code where the error emanates from looks like this: createFileWithParent :: FilePath -> FilePath -> IO () createFileWithParent file parent = do let filepath = parent </> file let dir = takeDirectory filepath putStrLn $ "createFileWithParent: file [" ++ file ++ "] dir [" ++ dir ++ "]" putStrLn $ "Ensuring dir: " ++ dir createDirectoryIfMissing True dir r <- doesDirectoryExist dir if r then do putStrLn $ "Ensured dir: " ++ dir when (not (null file)) $ do exists <- doesFileExist filepath if not exists then do putStrLn $ "Creating file: " ++ (parent </> file) openFile (parent </> file) WriteMode >>= hClose putStrLn $ "Created file: " ++ (parent </> file) else error $ "File exists: " ++ filepath else error $ "Could not create dir: " ++ dir The important thing in the code above is that we check that the file does not exist already, and we are creating it. Creating this new file intermittently fails with the following error messages, all of these are coming from prints in the above: createFileWithParent: file [file1] dir [/tmp/fsevent_dir-e1098325dc2b0880/watch-root] Ensuring dir: /tmp/fsevent_dir-e1098325dc2b0880/watch-root Ensured dir: /tmp/fsevent_dir-e1098325dc2b0880/watch-root Creating file: /tmp/fsevent_dir-e1098325dc2b0880/watch-root/file1 uncaught exception: IOException of type ResourceBusy /tmp/fsevent_dir-e1098325dc2b0880/watch-root/file1: openFile: resource busy (file is locked) How can a file that does not exist and being created be locked during creation? We see this only on Linux, the same tests always succeed on Windows and macOS. We are facing this in GHC 9.2.8, I am not sure if it is version specific because in the past I selectively disabled the tests for specific GHC versions and the error still surfaced in other GHC versions. Anything obvious that we may be missing here? Any pointers or more debug info to generate to debug this? I have not started looking into the openFile code yet, hoping someone else knowing it well might help here. Is this some other "resource busy" error which is being wrongly bucketed into "file is locked" error? Thanks, Harendra

4 20

CI hickups
by Andreas Klebinger 03 Jul '25

03 Jul '25

Hello devs, There are currently issues with the perf-notes repository tokken which cause CI pipelines to fail. If you see failures related to get being unable to fetch something this is the reason. We hope to fix this soon.

2 1

Build failure
by Simon Peyton Jones 30 Jun '25

30 Jun '25

Friends My build !14410 has started consistently failing to show me testsuite output etc. The tail of the log is s very long sequence of Haddock warnings. Something has changed and I don't think it's my MR! Does anyone have any idea what is happening? Thanks Simon

2 1

Request for approval of account
by Mark Seemann 24 Jun '25

24 Jun '25

Hello I’d like to report a bug in GHC because an error message tells me to do so. In order to do that, I’m trying to follow the guidelines in https://gitlab.haskell.org/ghc/ghc/-/wikis/report-a-bug, so I’ve created an account. The next step, as I understand it, is to use this mailing list to request approval for he account. I’m hereby doing that. TIA Mark Seemann

2 1