- ghc-devs - Haskell.org

GHC 9.6.7 is now available
by Luite Stegeman 24 Mar '25

24 Mar '25

The GHC developers are very pleased to announce the availability of GHC 9.6.7. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.6.7 We hope to have this release available via ghcup shortly. GHC 9.6.7 brings 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 - 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. 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 a try and open a [ticket] if you see anything amiss. ~ Luite [release notes]: https://downloads.haskell.org/ghc/9.6.7/docs/users_guide/9.6.7-notes.html [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

2 2

What should it mean for a record selector to be "covered"?
by Florian Ragwitz 23 Mar '25

23 Mar '25

Let's say you have data Foo = Foo { fooX, fooY :: Int } For coverage reporting, HPC creates a coverage box for each top-level definition. These boxes will be ticked appropriately at runtime when the fooX and fooY bindings are used directly. However, they won't be ticked if you pattern match on the constructor, such as f (Foo x y) = ... f Foo{ fooX = fooX } = ... f Foo{ fooX = x } = ... f Foo{ fooX } = ... f Foo{..} = ... and variations thereof. This is understandable, but can lead to some undesirable or unexpected behaviour for users of RecordWildCards or RecordPuns especially. E.g. https://gitlab.haskell.org/ghc/ghc/-/issues/17834 and https://github.com/PostgREST/postgrest/issues/2627#issuecomment-1435642297. GHC already seems to acknowledge this, at least to some extent, via its treatment of unused top-level binding warnings when using RecordWildCards, RecordPuns, or record patterns, where f Foo{ fooX } = ... or f Foo{ fooX = x } = ... will not emit a -Wunused-top-binds warning for fooX while still emitting one for fooY, and where f Foo{..} = ... will not emit any -Wunused-top-bind warnings at all. Given these observations, and assuming that the current HPC behaviour is undesirable, I’d like some guidance on what the exact desired behavior for HPC coverage should be for record selectors. In particular: * Should a record selector be considered "covered" simply by being bound in a pattern match? * Or should it only be marked as covered if the bound symbol is actually used? If the latter is preferable, would a change that initially marks them as covered upon binding (thereby aligning HPC with the treatment of unused binding warnings) be acceptable as an interim step toward the larger goal? Thanks for your time and insights!

1 0

fail to build ghc in github action
by chaowen guo 23 Mar '25

23 Mar '25

i fork the ghc repo from github and use the following workflow on: push jobs: build: runs-on: ubuntu-24.04 steps: - uses: actions/checkout@main - run: | git submodule update --init --recursive sudo apt install -y --no-install-recommends alex happy python3 boot ./configure hadrian/build Warning: Specifying an absolute path to the project file is deprecated. Use 1178 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>--project-dir to set the project's directory. 1179 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>Config file path source is default config file. 1180 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>Config file not found: /home/runner/.config/cabal/config 1181 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>Writing default configuration to /home/runner/.config/cabal/config 1182 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>Configuration is affected by the following files: 1183 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>- cabal.project 1184 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>Warning: The package list for 'hackage.haskell.org' does not exist. Run 'cabal 1185 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>update' to download it. 1186 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>Warning: There is no index-state for 'hackage.haskell.org' exactly at the 1187 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>requested timestamp (2025-01-27T17:45:32Z). Also, there are no index-states 1188 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>before the one requested, so the repository 'hackage.haskell.org' will be 1189 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>empty. 1190 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>Resolving dependencies... 1191 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>Error: [Cabal-7107] 1192 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>Could not resolve dependencies: 1193 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>[__0] trying: hadrian-0.1.0.0 (user goal) 1194 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>[__1] trying: hadrian:+selftest 1195 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>[__2] unknown package: QuickCheck (dependency of hadrian +selftest) 1196 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>[__2] fail (backjumping, conflict set: QuickCheck, hadrian, hadrian:selftest) 1197 <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896…>After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: hadrian, hadrian:selftest, QuickCheck i have no idea what happen. please help.

2 1

Haskell.org mailing list status
by Ben Gamari 20 Mar '25

20 Mar '25

Hi all, As you may have noticed, yesterday brought an unexpected influx of traffic from haskell.org's mailing lists. This was the result of fixing an interruption in mailing list message delivery which began in late February as a result of on-going infrastructure migration efforts. We are monitoring the situation to ensure that this issue does not recur but if you see anything amiss don't hesitate to contact admin(a)haskell.org. Thank you for your understanding and help! Cheers, - Ben

1 0

Gitlab access
by Jar Jar 19 Mar '25

19 Mar '25

Hi ghc-devs, Please accept gitlab access request for : spamdefence+haskell(a)torinthiel.pl Kind Regards, JJ

2 1

GHC 9.12.2 is now available
by Ben Gamari 14 Mar '25

14 Mar '25

The GHC developers are happy to announce the release of GHC 9.12.2. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org] We hope to have this release available via `ghcup` shortly. This is a small release fixing a critical code generation bug, #25653, affecting some subword division operations. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status]. We would like to thank 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 who contribute their code, tickets, and energy to the GHC project. As always, do give this release a try and open a [ticket] if you see anything amiss. [release notes]: https://downloads.haskell.org/ghc/9.12.2/docs/users_guide/9.12.2-notes.html [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.12.2 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

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

27 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