The GHC developers are very pleased to announce the availability of GHC
9.4.1. Binary distributions, source distributions, and documentation are
available at downloads.haskell.org.
This release includes:
A new profiling mode, -fprof-late, which adds automatic cost-center
annotations to all top-level functions after Core optimisation has
run. This provides informative profiles while interfering
significantly less with GHC’s aggressive optimisations, making it
easier to understand the performance of programs which depend upon
simplification…
A variety of plugin improvements including the introduction of a new
plugin type, defaulting plugins, and the ability for typechecking
plugins to rewrite type-families.
An improved constructed product result analysis, allowing unboxing of
nested structures, and a new boxity analysis, leading to less reboxing.
Introduction of a tag-check elision optimisation, bringing
significant performance improvements in strict programs.
Generalisation of a variety of primitive types to be levity
polymorphic. Consequently, the ArrayArray# type can at long last be
retired, replaced by standard Array#.
A complete overhaul of GHC’s Windows support. This includes a
migration to a fully Clang-based C toolchain, a deep refactoring of
the linker, and many fixes in WinIO.
Support for multiple home packages, significantly improving support
in IDEs and other tools for multi-package projects.
A refactoring of GHC’s error message infrastructure, allowing GHC to
provide diagnostic information to downstream consumers as structured
data, greatly easing IDE support.
Significant compile-time improvements to runtime and memory consumption.
On overhaul of our packaging infrastructure, allowing full
traceability of release artifacts and more reliable binary
distributions.
Reintroduction of deep subsumption (which was previously dropped with the simplified subsumption change) as a language extension.
… and much more. See the release notes for a full accounting.
Note that, as 9.4.1 is the first release for which the released artifacts will
all be generated by our Hadrian build system, it is possible that there will be
packaging issues. If you enounter trouble while using a binary distribution,
please open a ticket. Likewise, if you are a downstream packager, do consider
migrating to Hadrian to run your build; the Hadrian build system can be built
using cabal-install, stack, or the in-tree bootstrap script. See the accompanying blog post for details on migrating packaging to Hadrian.
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.
The aarch64-darwin seems to install some of the symlinks a bit wrong (I don’t think this is just ghcup!):
Sigh, indeed, I can reproduce this and it does look wrong. It appears that Darwin’s cp -P behaves differently from the same from coreutils. Bizarrely, it appears that one must pass cp -RP to reproduce the standard semantics.
Yes, it appears that BSD and coreutils differ in their behavior here; clearly we need to improve our testing coverage of the wrapper scripts.
I have fixed this issue in !8789. Needless to say, we will need to put out a 9.4.2 quite soon. In the meantime, BSD users can patch the binary distribution with,
Previous releases contained a directory ghc-9.2.4 in the archive. 9.4.1 instead has something like ghc-9.4.1-x86_64-unknown-linux for ghc-9.4.1-x86_64-deb10-linux.tar.xz. Unsure if this is a deliberate change.
It seems that deb11 is supported for x86_64 but there is no aarch64 release. Can we expect aarch64 deb11 support to appear at some point?
There is indeed automatic testing of bindists in every CI job. However, this particular issue was not caught because we used coreutils in our Darwin testing environment rather than Darwin’s native BSD tools. This is being fixed.
For the record, this issue is being tracked as GHC #21974.
That is to some extent true; I’d imagine there are quite a few Darwin users who are using coreutils, although we certainly can’t depend upon this fact.
It’s maintained by @hasufell although we do try to work with him to ensure it’s well-supported. Unfortunately, the Darwin bindist issue mentioned above complicates matters.
Why does: “ghcup install ghc”
seem to install ghc 8.10.7 by default instead of this newer version?
Also; I did a “ghcup install ghc 9.4.1” and it seemed to do it, but then running “ghc --version” still gives 8.10.2 , it seems I must manually edit the $PATH in the environment?