The GHC developers are happy to announce the availability of GHC 9.6.6. Binary
distributions, source distributions, and documentation are available on the release page.
This release is primarily a bugfix release addressing some issues
found in the 9.6 series. These include:
A fix for a bug in the NCG that could lead to incorrect runtime results due to
erroneously removing a jump instruction (#24507).
A fix for a linker error that manifested on certain platform/toolchain combinations,
particularly darwin with a brew provisioned toolchain, arising due to a confusion
in linker options between GHC and cabal (#22210).
A fix for a compiler panic in the simplifier due to incorrect eta expansion (#24718).
A fix for possible segfaults when using the bytecode interpreter due to incorrect
constructor tagging (#24870).
And a few more fixes
A full accounting of changes can be found in the release notes. As
some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.
We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool,
Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, 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.
I don’t see hls-powered attached with this. I thought changes between 9.6.5 and 9.6.6 were merely bugfixes rather than new features and don’t see any changes in base version as well.
So my assumption was that it would, by default, be supported by the hls-2.9.0.0.
if you don’t mind me asking, by when would we be able to use hls and cabal and a common ghc for both regular Haskell development and wasm or js development in haskell?
How far or close are we from that? Because after using Haskell, I want to continue using Haskell for everything.
I think the keyword you are looking for is “runtime retargetability”, i.e. being able to use a single GHC binary to compile for multiple targets. There is definitely work going on here by @romes and others, but I don’t know how close we are.
That’s right. I’m not actively working on it at the moment (even though it is on my priority list to get back to it when possible), but “runtime retargetability” would mean the same compiler could produce code for multiple targets such as x86_64, aarch64, JS, WASM, etc…
GHC has been coming closer than ever to being runtime retargetable over the years due to the work of many people, but there’s still a considerable amount of work to be done. As for me, I picked the project up in the toolchain configuration end of it and did a lot of progress on a tool to configure multiple targets and their toolchains that GHC can understand: ghc-toolchain. Here’s a blog post on it: Improving GHC's configuration logic and cross-compilation support with ghc-toolchain - Well-Typed: The Haskell Consultants