February 2025 - ghc-devs

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

06 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

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 memory usage when typechecking from source vs. loading ModIfaces
by Gergő Érdi 03 Apr '25

03 Apr '25

Hi, I’m using the GHC API to typecheck 35,000 modules that form a complicated dependency graph (with multiple top-level modules, i.e. there’s no single “god module” that would transitively depend on everything else), and I noticed that peak memory usage is wildly different when everything is done from scratch vs. when everything is loaded from files containing ModIfaces: 17G vs. 8G. This ratio replicates for smaller samples as well, e.g. 80M vs 33M for 407 modules. I’m aware of https://gitlab.haskell.org/ghc/ghc/-/issues/13586 and so when I finish typechecking a module, I take the resulting ModIface and create the ModDetails that ends up in the HomeUnitGraph from that. My understanding of Matt’s original GHC fix in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5478 is that it does the same, i.e. it only makes a fresh ModDetails only once per module, after the ModIface is ready. But of course that still means that ModDetails can only keep growing as more and more parts of it are used for typechecking more and more dependants. Could that be the cause? I tried a crude experiment of “putting the toothpaste back in the tube” by replacing all ModDetails with a fresh one in the HUG after each finished typechecking , but that’s a complete disaster for memory usage: even for the small 407 module example, the memory usage shoots up to 1.5G. I can imagine it’s because imported Ids are probably not shared anymore between different importer modules. Any ideas on how I could improve memory usage in the from-scratch case, so that it's more similar to the from-ModIface case? Thanks, Gergo

5 30

CFP - Haskell Implementors' Workshop 2025
by Andreas Herrmann 27 Mar '25

27 Mar '25

Call for proposals for the Haskell Implementors' Workshop https://haskell.foundation/events/2025-haskell-implementors-workshop.html June 6, 2025 Organized by the Haskell Community Co-located with ZuriHac 2025 and Haskell Ecosystem Workshop 2025 Hosted by the Haskell Foundation at Eastern Switzerland University of Applied Sciences (OST) https://www.ost.ch/en/university-of-applied-sciences/campus/rapperswil-jona… ## Overview * Deadline: April 4, 2025 * Notification: May 5, 2025 * Workshop: June 6, 2025 The 17th Haskell Implementors' Workshop is to be held alongside ZuriHac 2025 this year near Zurich. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure to share their work and to discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and lightning talks. In the past the Haskell Implementors’ Workshop was co-located with ICFP (International Conference on Functional Programming). However, in recent years it has become more and more challenging to attract a large enough audience and sufficiently many speakers for an appealing program. ZuriHac and the Haskell Ecosystem Workshop have become an important annual gathering of a large part of the Haskell community. This year the Haskell Implementors’ Workshop will be co-located with these events to be accessible to a broader audience. ## Scope and Target Audience The Haskell Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community are encouraged to attend the workshop - we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are especially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimization and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment ## Talks We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Submissions can be made via the form linked below until April 4, 2025 (anywhere on earth). https://docs.google.com/forms/d/e/1FAIpQLSdczGbxJYGc4eusvPrxwBbZl561PnKeYno… We will also have a lightning talks session. Lightning talks should be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. ## Program Committee * Luite Stegeman * Jaro Reinders * Emily Pillmore * Rodrigo Mesquita * Ian-Woo Kim * Andreas Herrmann (chair) ## Contact * Andreas Herrmann

1 1

GHC 9.12.2-rc1 is now available
by Ben Gamari 26 Feb '25

26 Feb '25

The GHC developers are happy to announce the availability of the first and likely final release candidate of GHC 9.12.2. This is an important bug-fix release resolving a significant correctness issue present in 9.12.1 (#25653). In accordance with our under-discussion [release policies] this candidate will have a two-week testing window. The final 9.12.2 release will likely come the week of 12 March 2025. As always, if you find anything amiss please open a [ticket]. Happy Haskelling! - Ben [release policies]: https://gitlab.haskell.org/ghc/ghc-hq/-/merge_requests/38 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

GHC API stability: draft report of actions
by Facundo Domínguez 26 Feb '25

26 Feb '25

Dear GHC devs, As part of the initiative to stabilize the GHC API [1], I've written a draft report [2] proposing actions to address some of the collected feedback. Some of these actions can potentially affect the processes used to maintain GHC, so your input is very much welcome to assess these or to propose other actions. [1] https://discourse.haskell.org/t/ghc-api-stability-update-3/11407 [2] https://docs.google.com/document/d/1w88bz03bZ9J7BP1WDxdpUTLqGrV4C9MAM1C06dD… Best, Facundo -- All views and opinions expressed in this email message are the personal opinions of the author and do not represent those of the organization or its customers.

1 1

How do I get warnings out of GHC.typecheckModule with GHC 9.12?
by Erdi, Gergo 25 Feb '25

25 Feb '25

PUBLIC Hi, I'm trying to use GHC.typecheckModule to typecheck a module. On GHC 9.8, this function used to expose renamer/typechecker-originating warnings to the GhcMonad that it is run in. However, as of e7a956623b7d71e50fa86fee83459d2611c423b8, the underlying function hscTypecheckRename has been refactored and now seems to discard warnings. At least, that's my read of the situation. End-to-end, what I'm seeing is that using GHC.typecheckModule, I can see the warnings come out from hscTypechekcRenameWithDiagnostics, but they never make it to printOrThrow. So how is GHC.typecheckModule supposed to be used by API clients in such a way that warnings are still passed to the logger stack? Thanks, Gergo ---------------------------------------------------------------------- This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries together with Standard Chartered Bank’s Privacy Policy via our public website. ---------------------------------------------------------------------- This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries together with Standard Chartered Bank’s Privacy Policy via our main Standard Chartered PLC (UK) website at sc. com

1 0

GHC 9.6.7 rc2 available
by Luite Stegeman 16 Feb '25

16 Feb '25

The GHC developers are very pleased to announce the availability of the second release candidate of GHC 9.6.7. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.6.7-rc2 We hope to have this release available via ghcup shortly. Haskell Language Server does not yet build with GHC 9.6.7. See the note below. If all goes according to plan, we expect that the final release of GHC 9.6.7 will be available on February 28. Release candidate 2 contains the following changes relative to (the unannounced) release candidate 1: - the symbol atomic_inc64 is no longer exported from the RTS GHC 9.6.7 will bring a number of fixes, including: - GHC’s internal Unique type has been widened to 64-bits on 32-bit architectures, avoiding potential miscompilations on large projects. - Fix a runtime crash when using the compacting GC, caused by black holes in large objects. - Added new flags -fspec-eval and -fspec-eval-dictfun to allow switching off speculative evaluation. The following libraries have been updated since GHC 9.6.6: - base-4.18.3.0 (the version number in the rc2 release notes is incorrect) - filepath-1.4.301.0 - unix-2.8.6.0 - bytestring-0.11.5.4 - array-0.5.8.0 A more detailed description can be found in the [release notes] and a full list of changes in [GHC!13841] and [GHC!13891] Note about Haskell Language Server and building GHC 9.8+: The change of Unique to 64 bit [GHC#22010] adds the exported symbol ghc_unique_counter64 to the RTS. Unfortunately it's impossible to avoid this without breaking other things. If you encounter a linker error related to ghc_unique_counter64 when building GHC (or building a GHC-derived package like ghc-lib-parser) with GHC 9.6.7, you probably have to add this [fix] to the program you're building. At the time of writing all released GHC 9.8 versions are affected, as well as the latest version of ghc-lib-parser-9.8 on hackage (which is a dependency of Haskell Language Server). We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, 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. Please give this release candidate a try and open a [ticket] if you see anything amiss. ~ Luite [release notes]: https://downloads.haskell.org/ghc/9.6.7-rc2/docs/users_guide/9.6.7-notes.ht… [GHC!13841]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13841 [GHC!13891]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13891 [GHC#22010]: https://gitlab.haskell.org/ghc/ghc/-/issues/22010 [fix] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13743 [ticket] https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

GHC 9.6.7 rc2 available
by Luite Stegeman 15 Feb '25

15 Feb '25

The GHC developers are very pleased to announce the availability of the second release candidate of GHC 9.6.7. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.6.7-rc2 We hope to have this release available via ghcup shortly. Haskell Language Server does not yet build with GHC 9.6.7. See the note below. If all goes according to plan, we expect that the final release of GHC 9.6.7 will be available on February 28. Release candidate 2 contains the following changes relative to (the unannounced) release candidate 1: - the symbol atomic_inc64 is no longer exported from the RTS GHC 9.6.7 will bring a number of fixes, including: - GHC’s internal Unique type has been widened to 64-bits on 32-bit architectures, avoiding potential miscompilations on large projects. - Fix a runtime crash when using the compacting GC, caused by black holes in large objects. - Added new flags -fspec-eval and -fspec-eval-dictfun to allow switching off speculative evaluation. The following libraries have been updated since GHC 9.6.6: - base-4.18.3.0 (the version number in the rc2 release notes is incorrect) - filepath-1.4.301.0 - unix-2.8.6.0 - bytestring-0.11.5.4 - array-0.5.8.0 A more detailed description can be found in the [release notes] and a full list of changes in [GHC!13841] and [GHC!13891] Note about Haskell Language Server and building GHC 9.8+: The change of Unique to 64 bit [GHC#22010] adds the exported symbol ghc_unique_counter64 to the RTS. Unfortunately it's impossible to avoid this without breaking other things. If you encounter a linker error related to ghc_unique_counter64 when building GHC (or building a GHC-derived package like ghc-lib-parser) with GHC 9.6.7, you probably have to add this [fix] to the program you're building. At the time of writing all released GHC 9.8 versions are affected, as well as the latest version of ghc-lib-parser-9.8 on hackage (which is a dependency of Haskell Language Server). We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, 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. Please give this release candidate a try and open a [ticket] if you see anything amiss. ~ Luite [release notes]: https://downloads.haskell.org/ghc/9.6.7-rc2/docs/users_guide/9.6.7-notes.ht… [GHC!13841]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13841 [GHC!13891]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13891 [GHC#22010]: https://gitlab.haskell.org/ghc/ghc/-/issues/22010 [fix] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13743 [ticket] https://gitlab.haskell.org/ghc/ghc/-/issues/new P.S. Apologies if you already received this mail.

1 0

GHC 9.6.7 rc2 available
by Luite Stegeman 13 Feb '25

13 Feb '25

The GHC developers are very pleased to announce the availability of the second release candidate of GHC 9.6.7. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.6.7-rc2 We hope to have this release available via ghcup shortly. Haskell Language Server does not yet build with GHC 9.6.7. See the note below. If all goes according to plan, we expect that the final release of GHC 9.6.7 will be available on February 28. Release candidate 2 contains the following changes relative to (the unannounced) release candidate 1: - the symbol atomic_inc64 is no longer exported from the RTS GHC 9.6.7 will bring a number of fixes, including: - GHC’s internal Unique type has been widened to 64-bits on 32-bit architectures, avoiding potential miscompilations on large projects. - Fix a runtime crash when using the compacting GC, caused by black holes in large objects. - Added new flags -fspec-eval and -fspec-eval-dictfun to allow switching off speculative evaluation. The following libraries have been updated since GHC 9.6.6: - base-4.18.3.0 (the version number in the rc2 release notes is incorrect) - filepath-1.4.301.0 - unix-2.8.6.0 - bytestring-0.11.5.4 - array-0.5.8.0 A more detailed description can be found in the [release notes] and a full list of changes in [GHC!13841] and [GHC!13891] Note about Haskell Language Server and building GHC 9.8+: The change of Unique to 64 bit [GHC#22010] adds the exported symbol ghc_unique_counter64 to the RTS. Unfortunately it's impossible to avoid this without breaking other things. If you encounter a linker error related to ghc_unique_counter64 when building GHC (or building a GHC-derived package like ghc-lib-parser) with GHC 9.6.7, you probably have to add this [fix] to the program you're building. At the time of writing all released GHC 9.8 versions are affected, as well as the latest version of ghc-lib-parser-9.8 on hackage (which is a dependency of Haskell Language Server). We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, 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. Please give this release candidate a try and open a [ticket] if you see anything amiss. ~ Luite [release notes]: https://downloads.haskell.org/ghc/9.6.7-rc2/docs/users_guide/9.6.7-notes.ht… [GHC!13841]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13841 [GHC!13891]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13891 [GHC#22010]: https://gitlab.haskell.org/ghc/ghc/-/issues/22010 [fix] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13743 [ticket] https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0