- ghc-devs - Haskell.org

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

GHC 9.14 status
by Ben Gamari 21 Jun '25

21 Jun '25

Hi all, We are coming up on the final fork for the ghc-9.14 branch. I expect that Vlad's !14136 will land in the next day. The submodule bumps will likely land shortly after. At this rate I expect the fork to be cut on Tuesday, with the first alphas coming around a week after. Naturally, if I have missed anything let me know ASAP. Cheers, - Ben

1 0

RTS: mmap fails on RISC-V with Linux 6.8
by Heinrich Schuchardt 20 Jun '25

20 Jun '25

The following bug related to the Haskell runtime was reported in Launchpad: Haskell's default behaviour of using large-address-space is causing pandoc to stuck in an infinite loop on QEMU 10 Edit https://bugs.launchpad.net/ubuntu/+source/ghc/+bug/2111581 The problem seems to relate to the following loop in osReserveHeapMemory(): https://gitlab.haskell.org/ghc/ghc/-/blob/master/rts/posix/OSMem.c?ref_type… According to the mmap() manpage the address passed to the kernel in only a hint there is no guarantee that the same address will be used for allocation. As shown in the strace logs attached in Launchpad this code can lead to an endless loop when the kernel decides always to return an address below 8 GiB. It might make sense to round up the address to 8 GiB if the returned address is below 8 GiB and reduce *len accordingly instead of retrying. Best regards Heinrich

2 2

Placing GitLab behind Anubis
by Ben Gamari 17 Jun '25

17 Jun '25

Hi all, As you may know, for the last few years we have used a variety of strategies for dealing with the problem of abuse and spam on gitlab.haskell.org. The currently-employed and seemingly most effective technique has been to require manual approval of new account requests. This has always been an uneasy compromise. Not only does this approval process add considerable friction to the contribution process, the increasing prevalence of ill-behaved web crawlers has rendered the approach less and less effective at prevent that form of abuse. For this reason we now exploring alternative approaches. One promising strategy employed by other FOSS GitLab deployments (e.g. gitlab.freedesktop.org) is the Anubis proof-of-work system. Anubis works by forcing the client to perform a small (but non-negligible) amount of work before requests are serviced. This will mean that GitLab users' clients will periodically be asked to perform small amounts of work. While Anubis primarily targets crawlers, it may be that the slight increase in per-request cost might also allow us to lift our manual account approval requirement. Ultimately, the only way to find out is to try. If there are no objections, I will place Anubis in front of GitLab starting next week. During this process we will assess the effectiveness of Anubis at prevent both spam and over-zealous crawlers. This may require a bit of iterative parameter tuning but I am hopeful that the end result might be a more accessible and faster GitLab instance for us all. Let me know what you think. Cheers, - Ben [1] https://github.com/TecharoHQ/anubis

4 3

GHC 9.14 fork status
by Ben Gamari 13 Jun '25

13 Jun '25

Hi all, As those of you at Zurihac may know, we are currently in the process of preparing for the GHC 9.14 fork. This week I have been working through the various necessary core library version bumps and submodule changes. My hope is that we can land this work early next week and declare the fork at some point in the days that follow. I am aware of a few things that we want to land prior to forking: * @int-index's !14136 (Visible forall in GADTs) * testing and enabling of LLVM 20 support * an update of win32-tarballs * Cheng's libffi update (!14392) If you have any further work that you would like to see in 9.14 please do let me know by next Wednesday. If all goes well, my hope is that we can have our first alpha out by the end of this month, with an eye towards a final release in early September. Cheers, - Ben

2 1