The GHC developers are very pleased to announce the availability of the first alpha prerelease of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
GHC 9.14 will bring a number of new features and improvements, including:
Significant improvements in specialisation:
The SPECIALISE pragma now allows use of type application syntax
The SPECIALISE pragma can be used to specialise for expression arguments as well as type arguments.
Specialisation is now considerably more reliable in the presence of newtypes
the specialiser is now able to produce specialisations with polymorphic typeclass constraints, considerably broadening its scope.
Significant improvements in the GHCi debugger
Record fields can be defined to be non-linear when LinearTypes is enabled.
RequiredTypeArgments can now be used in more contexts
SSE/AVX support in the x86 native code generator backend
A major update of the Windows toolchain
… and many more
A full accounting of changes can be found in the release notes. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads.
Due to unexpected complications, this initial prerelease comes a bit later than expected. Consequently, we expect to have three condensed alphas prior to the release candidate. We expect the next alpha will come the week of 9 Sept. 2025, while the third will come 23 Sept. 2025, with the release candidate coming 7 Oct. 2025.
We would like to thank the Zw3rk stake pool, Well-Typed, Mercury, Channable, Tweag I/O, Serokell, 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.
Add a setup-info dictionary to a configuration file with the applicable entry for your operating system. For example, on Windows, a stack.yaml:
snapshot: nightly-2025-08-20 # GHC 9.12.2
compiler: ghc-9.14.0.20250819
compiler-check: match-exact # Anticipate future alpha releases
# Only required before the GHC version has been installed:
setup-info:
ghc:
windows64:
9.14.0.20250819:
url: https://downloads.haskell.org/ghc/9.14.1-alpha1/ghc-9.14.0.20250819-x86_64-unknown-mingw32.tar.xz
# Can be extended with SHA protections etc: see https://docs.haskellstack.org/en/stable/yaml_configuration/#setup-info
Hi @Darwin226; I’ve been working on the debugger improvements. Could you be more specific regarding what you tried and doesn’t work? I’d be happy to improve on it.
We’ve also developed a standalone debugger application compatible with VSCode, akin to HLS (it is also compatible with other DAP clients). I’m testing the application against the 9.14 alpha, and will announce it when published.
It’s worth pointing out that with 9.14 being the first supported release, the debugger improvements and debugger application should be considered somewhat experimental as they mature and bug reports come in.
Oh, sorry. I think my sentence could have benefited from some parentheses haha
I meant I don’t see (the debugger improvements mentioned) (in the linked release notes). I’d like to read more about them, but I can’t find the information.
The GHC API now exposes the primitives necessary to implement the debugger application with editor integration we’re developing (to be announced!)
Unfortunately, many changes beyond these ones didn’t make the 9.14.1 release. Specifically, step-out in 9.14 has some quirks and should be considered a tech preview. The follow up work is in !14534. We also landed some internal refactorings in 9.14.1 which facilitate further work on the debugger.
Since most Windows users do not have a C compiler/linker, GHC has long shipped with its own Clang toolchain, derived from msys2 packaging. The last several releases we did not upgrade this toolchain but for 9.14 we felt it was time to do so.
Even in the best of times such upgrades will typically have effects on GHC. In this particular case we were hit with Microsoft’s restructuring of its standard libraries into so-called API sets as well as changes in the archive format emitted by Clang. Both of these required changes in GHC and its runtime system linker to accommodate.
Thank you for more details! There’s currently an issue if you try to link Rust static library with Haskell on Windows (tested with GHC 9.4 through 9.12, and some of the 8.*). ld.lld: error: undefined symbol: _fltused (also vftable, __chkstk and 8 more items). Is there a chance that this is fixed by the Clang toolchain upgrade?
Thank you for the suggestion! After using this config and x86_64-pc-windows-gnu target there’s a different error (tested with ghc 9.12.2):
ld.lld: warning: ignoring unknown argument: -exclude-symbols:_ZN4core4time8Duration10from_nanos17h8238e7f825b62759E
…
ld.lld: error: -exclude-symbols:_ZN4core4time8Duration10from_nanos17h8238e7f825b62759E is not allowed in .drectve
…
The function from error message is most likely Duration::from_nanos from Rust std. I’m using this repo for quick build tests:
In case I’m building a UI app, should I use x86_64-pc-windows-msvc or x86_64-pc-windows-gnu Rust target? I guess, msvc is a proper target for both Rust and Haskell.
I did try this, but no luck either. When I try to use cc as a linker, Rust compilation fails with:
lld: error: unable to find library -lgcc_eh
lld: error: unable to find library -lgcc
cc: error: linker command failed with exit code 1 (use -v to see invocation)
I think cc linker is not supported in Rust and some extra steps are required to make it work.
And when I only use gnu toolchain with default linker, the error is:
error: failed to run custom build command for `proc-macro2 v1.0.101`
Caused by:
could not execute process `...\future-hs\target\debug\build\proc-macro2-...\build-script-build` (never executed)
Caused by:
%1 is not a valid Win32 application. (os error 193)
I think that many Rust crates just don’t support gnu toolchain on Windows.
Coming back to Haskell,
I don’t think you can compile with GHC using msvc.
That’s sad we can’t compile with msvc. Is there any hope for Haskell to get msvc support in the future? There’s a real use case to build crossplatform UI applications which may drive Haskell adoption.
Unless someone invests in adding support I would say that it is unlikely. Maintaining support for even a single Windows toolchain is a challenge, especially given the rarity of Windows knowledge among open-source contributors. Adding support for MSVC, which brings its own set of unique challenges, would likely be a non-trivial project (although I could be pleasantly surprised).
For what it’s worth, an MSVC port of GHC 8.10 was developed and announced several years back; sadly it was never open-sourced.
What if you download MSYS2, use pacman to get the mingw with libgcc, point Cargo to that mingw, and then point Cabal to that mingw (with gcc-location, ld-location, extra-libs for the includes of mingw, etc)?
FWIW, haskell.nix has a bunch of msvcrt support patches for later GHC releases, as we were stuck with msvcrt due to cross compilation issues with ucrt64. I’m not sure how long we’ll keep msvcrt around, but there is in principle both in there right now urct64 and msvcrt.
