GHC 10.0.1-alpha1 is now available

Announcements
1

The GHC developers are very pleased to announce the availability of the
first alpha prerelease of GHC 10.0.1. Binary distributions, source
distributions, and documentation are available at downloads.haskell.org and
via GHCup.

GHC 10.0 will bring a number of new features and improvements, including:

  • The default language edition is now GHC2024
    (GHC Proposal #632, #26039).

  • Type and Constraint are now completely distinct types, just as much as
    Int and Bool (#24279).

  • The new QualifiedStrings language extension
    (GHC Proposal #723) allows string literals to be
    qualified using module qualification syntax, so that M."my string"
    desugars toM.fromString "my string".

  • The treatment of static forms has been simplified, implementing
    GHC Proposal #732 (#26556). The free term variables of
    (static e) must now be bound at top level.

  • -fpolymorphic-specialisation is now (re)enabled by default (#23559),

  • Bytecode can now be written to disk with -fwrite-byte-code and packaged
    into bytecode libraries with -bytecodelib, which the interpreter can use
    to satisfy package dependencies (#26298).

  • Executables can now be properly statically linked with the new
    -fully-static and -static-external flags (#26434).

  • SIMD support in the AArch64 native code generator (#26536).

  • A new poll I/O manager, which is now the default in the single-threaded
    RTS on all POSIX platforms except macOS (!9677).

  • Version 2 of the GHC Jobserver Protocol for GHC’s -jsem
    jobserver on Linux and other POSIX platforms (#25087, #27253). This is
    sadly a necessary breaking change. -jsem requires cabal-install 3.18 or
    later, and is otherwise ignored with a warning, falling back to sequential
    compilation.

  • Changes to base:

    • GHC.Num.{BigNat,Integer,Natural} are no longer exposed
      (CLC #359) and GHC internals in GHC.Num are deprecated
      (CLC #360).

    • Data.List.init and Data.List.last now carry an x-partial warning
      (CLC #292).

  • The minimum bootstrap compiler is now GHC 9.10, LLVM versions up to 23 are
    supported (#26813, #27764), and the Debian 9, Debian 10, Ubuntu 18.04
    and Ubuntu 20.04 bindists have been dropped in favour of a new Debian 13
    bindist (#25876).

  • … and many more

A full accounting of changes can be found in the release notes.
See the migration guide for guidance on migrating programs to this release.
As always, GHC’s release status, including planned future releases, can be
found on the GHC Wiki status.

Given the many changes in this major release, we would very much appreciate
testing on downstream workloads.

GHC development is sponsored by:

We would like to thank these sponsors 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.

42 Likes
2

I tried to do my usual thing with Stack on Windows 11, but it failed when trying to build simple Setup.hs. I tried the command that it failed on locally, which was as follows (reformatted for clarity):

> D:\sr\programs\x86_64-windows\ghc-10.0.0.20260917\bin\ghc-10.0.0.20260917.exe 
  -rtsopts 
  -threaded 
  -clear-package-db 
  -global-package-db 
  -hide-all-packages 
  -package base 
  -main-is StackSetupShim.mainOverride 
  -package Cabal-3.18.1.0 
  D:\sr\setup-exe-src\setup-O_vy6YIf.hs 
  D:\sr\setup-exe-src\setup-shim-O_vy6YIf.hs 
  -o D:\sr\setup-exe-cache\x86_64-windows\tmp-Cabal-simple_O_vy6YIf_3.18.1.0_ghc-10.0.0.20260917.exe

and that command failed with a rather odd message from GHC (reformatted for clarity):

ghc-10.0.0.20260917.exe: 
  Haskell C pre-processor: 
    could not execute: 
      C:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//bin/clang.exe

I don’t know why ghc-10.0.0.20260917.exe would be looking there (which does not exist) for clang.exe, when the GHC-supplied clang.exe is at its usual place relative to the GHC executable:

D:\sr\programs\x86_64-windows\ghc-10.0.0.20260917\mingw\bin\clang.exe

I wondered if something in GHC 10.0.1-alpha1 had inadvently hard-coded a dud path to clang.exe?

EDIT1: D:\sr\programs\x86_64-windows\ghc-10.0.0.20260917\bin\ghc-10.0.0.20260917.exe --info yields (extracts only):

[("Project name","The Glorious Glasgow Haskell Compilation System")
...
 ,("C compiler command","C:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//bin/clang.exe")
 ,("C compiler flags","--target=x86_64-unknown-windows-gnu --rtlib=compiler-rt -D_UCRT -IC:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//include -Qunused-arguments")
 ,("C++ compiler command","C:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//bin/clang++.exe")
 ,("C++ compiler flags","--target=x86_64-unknown-windows-gnu -IC:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//include")
 ,("C compiler link flags","--target=x86_64-unknown-windows-gnu -fuse-ld=lld --rtlib=compiler-rt -D_UCRT -LC:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//lib -LC:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//x86_64-w64-mingw32/lib -fstack-check")
...
 ,("CPP command","C:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//bin/clang.exe")
 ,("CPP flags","-IC:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//include -E")
 ,("Haskell CPP command","C:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//bin/clang.exe")
 ,("Haskell CPP flags","-IC:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//include -E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs")
 ,("JavaScript CPP command","C:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//bin/clang.exe")
...
 ,("C-- CPP command","C:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//bin/clang.exe")
 ,("C-- CPP flags","-IC:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//include -E")
...
 ,("ar command","C:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw/bin/llvm-ar.exe")
...
 ,("ranlib command","C:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//bin/llvm-ranlib.exe")
...
 ,("windres command","C:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//bin/llvm-windres.exe")
...
 ,("LLVM llc command","C:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//bin/llc.exe")
 ,("LLVM opt command","C:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//bin/opt.exe")
 ,("LLVM llvm-as command","C:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32/mingw//bin/clang.exe")
...
 ,("Project version","10.0.0.20260917")
 ,("Project Git commit id","26df2c83f386f5bfbac7ca9e83b3822355248442")
...
 ,("Target platform","x86_64-unknown-mingw32")
...
 ,("LibDir","D:\\sr\\programs\\x86_64-windows\\ghc-10.0.0.20260917\\lib")
 ,("Global Package DB","D:\\sr\\programs\\x86_64-windows\\ghc-10.0.0.20260917\\lib\\package.conf.d")
 ]

EDIT2: The workaround is to patch the paths in “…\ghc-10.0.0.20260917\lib\targets\default.target”. However, doing so reveals that Stack’s Setup.hs can’t build against Cabal-3.18.1.0 (some types have changed). So, I’ll need to update Stack before it can support GHC 10.0.

EDIT3: The Stack side of things is now fixed in the master branch version of Stack.

2 Likes
3

Just a question related to SIMD. Are there any plans to support stuff like MoveMask that would enable faster SIMD style parser implementations?

4

Apparently, this issue affects 10.0.1-alpha1: nightly bindist for Windows contains hard-coded path to Clang (#27672) · Issue · ghc/ghc

1 Like
5

I don’t think there is a ticket for it. A ticket describing concrete use cases would be appreciated. I understand that there are many SIMD instructions not supported by GHC, but I have little idea on how to prioritize them. If there is a request for an instruction, I (or someone else) can implement it (I did the work on AArch64 NCG SIMD).

4 Likes
6

Ok. I’ll try to do a write up in a month or so. I might explore the GHC a bit and try to make a PR myself if it’s not too big of a deal.

7

newbie here

How can I install it via GHCup?

I have not been able to try 9.14.2 too..

Dowe have to change channel or something?

8

You could try the vanilla channel GitHub - haskell/ghcup-metadata: GHCup metadata repository · GitHub

2 Likes
9

Thanks, will chck this!

10

If you want to use GHC 10.0.1-alpha1 with Stack:

  1. Upgrade Stack to the master branch version of Stack. (Warning: if you use GHCup to manage versions of Stack, do not use Stack’s upgrade command.)

  2. Add a setup-info dictionary to a configuration file with the applicable entry for your operating system. For example, on Windows or macOS/AArch64, a stack.yaml:

snapshot: nightly-2026-09-19 # GHC 9.12.4
compiler: ghc-10.0.0.20260917
compiler-check: match-exact # Anticipating possible future alpha/RC releases

# Only required before the GHC version has been installed:
setup-info:
  ghc:
    windows64:
      10.0.0.20260917:
        url: https://downloads.haskell.org/ghc/10.0.1-alpha1/ghc-10.0.0.20260917-x86_64-unknown-mingw32.tar.xz
        # Can be extended with SHA protections etc: see https://docs.haskellstack.org/en/stable/configure/yaml/non-project/#setup-info
    macosx-aarch64:
      10.0.0.20260917:
        url: https://downloads.haskell.org/ghc/10.0.1-alpha1/ghc-10.0.0.20260917-aarch64-apple-darwin.tar.bz2
        # Can be extended with SHA protections etc: see https://docs.haskellstack.org/en/stable/configure/yaml/non-project/#setup-info

  1. Cause Stack to fetch and install GHC 10.0.1-alpha1 (eg command stack build). On Windows, GHC will fail until it is patched, due to GHC issue #27672.

  2. On Windows only, patch GHC’s broken default.target file, as follows (PowerShell):

> $ghc = "$(stack path --programs)\ghc-10.0.0.20260917"
> $badpath = [regex]::Escape('C:/GitLab-Runner/builds/2/2650043/_build/bindist/ghc-10.0.0.20260917-x86_64-unknown-mingw32')
> (Get-Content "$ghc\lib\targets\default.target") -replace $badpath, $ghc.Replace('\','\\') | Set-Content "$ghc\lib\targets\default.target"
1 Like
11

Could these prereleases contain codenames, like ghc-9.14.2-r2 or ghc-10.0-alpha1, not timestamps? They used to be like this, then at some point changed to contain timestamps, but timestamps are much harder to remember.

3 Likes
12

It does have a codename - it is tagged as ghc-10.0.1-alpha1 in the repository, and available at Index of /ghc/10.0.1-alpha1/

If you are talking about ghcup, I don’t think it has ever supported these monikers.

13

It does have a codename - it is tagged as ghc-10.0.1-alpha1 in the repository, and available at https://downloads.haskell.org/\~ghc/10.0.1-alpha1/

All the binaries you’re getting from tarballs have suffixes -10.0.0.20260917, not -10.0.1-alpha1, that’s mostly what I meant.

14

That has also been like that since time immemorial: Index of /ghc/6.10.2-rc1/ has ghc-6.10.1.20090314-i386-unknown-linux.tar.bz2

If it’s helpful we can start adding symlinks to the download directory, so that https://downloads.haskell.org/~ghc/10.0.1-alpha1/ghc-10.0.1-alpha1-aarch64-deb12-linux.tar.xz gets you https://downloads.haskell.org/~ghc/10.0.0.20260917/ghc-10.0.0.20260917-aarch64-deb12-linux.tar.xz , but the file you download would still be the “full” version number and not the moniker. I don’t think its a good idea to duplicate all the files on the server given the explosion in variants and bindist sizes in recent years, it’s probably not a good idea to double the storage requirements on top of that for little gain.

15

Ok, fair. I must’ve imagined things, because I was pretty sure it was like that in the past, but apparently not :cry: