GHC 9.10.1 release candidate 1 is now available!

The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.10.1. Binary distributions, source distributions, and documentation are available at and via GHCup.

GHC 9.10 brings a number of new features and improvements, including:

  • The introduction of the GHC2024 language edition, building upon GHC2021 with the addition of a number of widely-used extensions.

  • Partial implementation of the GHC Proposal #281, allowing visible quantification to be used in the types of terms.

  • Extension of LinearTypes to allow linear let and where bindings

  • The implementation of the exception backtrace proposal, allowing the annotation of exceptions with backtraces, as well as other user-defined context

  • Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely

  • Javascript FFI support in the WebAssembly backend

  • Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector.

  • … and many more

A full accounting of changes can be found in the release notes. As always, GHC’s release status, including planned future releases, can be found on the GHC Wiki status.

This is the penultimate prerelease leading to 9.10.1. In two weeks we plan to publish a release candidate, followed, if all things go well, by the final release a week later.

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.

As always, do give this release a try and open a ticket if you see anything amiss.


Is it safe to say that between RC and release there won’t be any breaking changes?

A number of maintainers have declined PRs that fix compatibility with GHC 9.10 with the current alphas. Maybe, if RCs have stronger guarantees, such PRs could be more convincing?

1 Like

it looks like that link isn’t up yet!

Sigh, it appears the CDN strikes again. I’ve purged it yet again.

1 Like

My memory is far from perfect but I cannot recall an instance where GHC broke compatibility between a release candidate and the final release. In almost every case the release candidate and the final differ in only very minor ways. I am hesitant to make fast promises, but in my opinion it should be fairly safe to assume interface stability from alpha 3 onwards.

1 Like

@bgamari the announcement says “release candidate” in its title, but then confusingly proceeds with

This alpha is the penultimate prerelease leading to 9.10.1. In two weeks we plan to publish a release candidate, followed, if all things go well, by the final release a week later.

So which one is it? :wink:

Like the alphas beforehand, if you want to use with Stack:

[1] Either (a) upgrade to the master branch version of Stack (can be used only if you are not using GHCup to manage versions of Stack): stack upgrade --source-only --git; or (b) test the first release candidate for Stack 2.15.7.

[2A] If you are not using GHCup to manage versions of GHC, augment Stack’s default setup-info dictionary in a configuration file (needed only until Stack has fetched the compiler once). For example, on Windows:

        # Can be extended with SHA protections etc: see

[2B] If you are using GHCup to manage versions of GHC, you can augment ~/.ghcup/config.yaml. For example, either:


  - StackSetupURL
  - setup-info:

            # Can be extended with SHA protections etc: see

or, alternatively:


  - StackSetupURL 

[3] Specify the compiler in a Stack configuration file (eg stack.yaml):

compiler: ghc-
1 Like

Sigh, yes, thanks @Bodigrim . Fixed!


Thanks! I’ll be poking around :slight_smile:

I thought a “release candidate” would be released unchanged unless something comes up.


Judging from Add GHC 9.10.1-rc1 by bgamari · Pull Request #206 · haskell/ghcup-metadata · GitHub it requires opt-ing into the prerelease channel and asking ghcup to install, right?

1 Like


ghcup config add-release-channel
ghcup install ghc
1 Like

Ah, great, this works with

    - uses: haskell-actions/setup@v2
        ghc-version: ${{ env.ghc_version }}

and the ghcup-release-channel setting does not disable the normal channel, I was worried that this would complicate matrix builds too much.

1 Like

I’m not a haskell setup action user, but I don’t see why the prerelease channel can’t be included by default for CI settings. It won’t override any existing versions and doesn’t change the latest tag either. It should be safe.

Maybe it makes sense to open an issue.

I also created Easier selection of known release channels · Issue #1050 · haskell/ghcup-hs · GitHub


Thanks! I noticed this because I was looking at 24374. Normally email is sent to etc. but I didn’t see one this time. Maybe I missed it, if not you might want to send to these mailing lists.

Not important for the release but can anybody on Apple Silicon and llvm 18 reproduce #24735 , “can’t compile with llvm 18 on ghc 9.10.1-rc1 on Apple Silicon” It would be nice to know if this is specific to me or if it is a more general issue.