[Haskell] [ANNOUNCE] GHC 9.0.2 released

The GHC developers are very happy to at long last announce the availability of GHC 9.0.2. Binary distributions, source distributions, and documentation are available at the [usual place](https://downloads.haskell.org/ghc/9.0.2/). Download Page: https://www.haskell.org/ghc/download_ghc_9_0_2.html Blog Post: https://www.haskell.org/ghc/blog/20211225-ghc-9.0.2-released.html GHC 9.0.2 adds first class AArch64/Darwin support using the LLVM backend, as well as fixing a number of critical correctness bugs with the 9.0.1 release, along with numerous improvements to compiler performance and memory usage: * First-class support for Apple M1 hardware using GHC's LLVM ARM backend. * Fix a number of incorrect rewrite rules for `fromInteger` (#19345, #20066). * Fix a number of runtime system and GC bugs which typically manifested in crashes (#19417, #19297, #19645, #19667, #18033, #20132, #19715, #20399, #20414, #20649, #19147, #20051, #20093) * Fixes for various compiler performance and memory usage issues (#20134, #13586, #20509, #19668, #19996, #19471) * Improvements and bug fixes for the code generator and optimiser (#18638, #19581, #19700, #19996, #19181, #19822) * Fixes for typechecker bugs (#19410 , #19191, #19522, #19400, #19849) * Bug fixes for the frontend and parser (#19397, #19838, #19518, #19777, #20242, #19786) * Emit warnings if Unicode Bidirectional Formatting characters are found in the source, possibly misleading code reviewers (#20263). * Many packaging related fixes, including versioned `ghc-pkg` executables (#20087), and actually distributing GHC versions linked against the `native` big integer backend (#18967, #19953) on both Windows and Alpine Linux. Some previous releases were still linked against the `GMP` library due to a misconfiguration of the builders. * A significant refactoring of `process` fixing numerous bugs mostly on Apple platforms (#19994, [process refactoring](https://github.com/haskell/process/pull/208)). * Bug fixes for the linker on Darwin platforms (#20004, #19968, #19950). A complete list of bug fixes and improvements can be found in the [release notes](https://downloads.haskell.org/ghc/9.0.2/docs/html/users_guide/9.0.2-notes.ht...). Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do open a [ticket][] if you see anything amiss. Happy Holidays and Happy Hacking! - Zubin

First of all a big thank you and congratulations on the highly anticipated
9.0.2 release.
I have been putting off this mail for a while:
I actually built it last month right away in Fedora's new ghc9.0 package
(available now for all current Fedora releases).
Also Stackage Nightly (primarily thanks to Adam Bergmark) was updated to
9.0.2, since nightly-2022-01-10. :-)
However two points I wanted to mention:
- firstly (minor), the libraries/containers source is not clean (which
explains why the tarball is so big)
- More serious: why was Win32 major bumped from 2.10 to 2.12?
- this breaks foundation, hence current Stackage Nightly is kind of
broken for Windows now:
https://github.com/commercialhaskell/stackage/issues/6400
I can't really see any good way to resolve this in the short term.
Thanks, Jens
On Sun, 26 Dec 2021 at 04:23, Zubin Duggal
The GHC developers are very happy to at long last announce the availability of GHC 9.0.2. Binary distributions, source distributions, and documentation are available at the [usual place](https://downloads.haskell.org/ghc/9.0.2/).

Could you explain what you mean about the containers source not being
"clean"?
On Sun, Jan 23, 2022, 2:31 AM Jens Petersen
First of all a big thank you and congratulations on the highly anticipated 9.0.2 release.
I have been putting off this mail for a while: I actually built it last month right away in Fedora's new ghc9.0 package (available now for all current Fedora releases). Also Stackage Nightly (primarily thanks to Adam Bergmark) was updated to 9.0.2, since nightly-2022-01-10. :-)
However two points I wanted to mention:
- firstly (minor), the libraries/containers source is not clean (which explains why the tarball is so big)
- More serious: why was Win32 major bumped from 2.10 to 2.12? - this breaks foundation, hence current Stackage Nightly is kind of broken for Windows now: https://github.com/commercialhaskell/stackage/issues/6400
I can't really see any good way to resolve this in the short term.
Thanks, Jens
On Sun, 26 Dec 2021 at 04:23, Zubin Duggal
wrote: The GHC developers are very happy to at long last announce the availability of GHC 9.0.2. Binary distributions, source distributions, and documentation are available at the [usual place](https://downloads.haskell.org/ghc/9.0.2/).
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

On Sun, 23 Jan 2022 at 15:40, David Feuer
Could you explain what you mean about the containers source not being "clean"?
I forgot to say "in the source tarball" explicitly.
If you look in libraries/containers/containers/dist-install, you can see
what I am talking about.
(I first discovered this because it broke the Fedora build - so I just
remove it before building.)
Jens
On Sun, Jan 23, 2022, 2:31 AM Jens Petersen
First of all a big thank you and congratulations on the highly anticipated 9.0.2 release.
I have been putting off this mail for a while: I actually built it last month right away in Fedora's new ghc9.0 package (available now for all current Fedora releases). Also Stackage Nightly (primarily thanks to Adam Bergmark) was updated to 9.0.2, since nightly-2022-01-10. :-)
However two points I wanted to mention:
- firstly (minor), the libraries/containers source is not clean (which explains why the tarball is so big)
- More serious: why was Win32 major bumped from 2.10 to 2.12? - this breaks foundation, hence current Stackage Nightly is kind of broken for Windows now: https://github.com/commercialhaskell/stackage/issues/6400
I can't really see any good way to resolve this in the short term.
Thanks, Jens
On Sun, 26 Dec 2021 at 04:23, Zubin Duggal
wrote: The GHC developers are very happy to at long last announce the availability of GHC 9.0.2. Binary distributions, source distributions, and documentation are available at the [usual place](https://downloads.haskell.org/ghc/9.0.2/).
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

There's no such directory in the Hackage or GitHub source. I guess it must
have crept in on the GHC side?
On Sun, Jan 23, 2022, 4:13 AM Jens Petersen
On Sun, 23 Jan 2022 at 15:40, David Feuer
wrote: Could you explain what you mean about the containers source not being "clean"?
I forgot to say "in the source tarball" explicitly. If you look in libraries/containers/containers/dist-install, you can see what I am talking about. (I first discovered this because it broke the Fedora build - so I just remove it before building.)
Jens
On Sun, Jan 23, 2022, 2:31 AM Jens Petersen
wrote: First of all a big thank you and congratulations on the highly anticipated 9.0.2 release.
I have been putting off this mail for a while: I actually built it last month right away in Fedora's new ghc9.0 package (available now for all current Fedora releases). Also Stackage Nightly (primarily thanks to Adam Bergmark) was updated to 9.0.2, since nightly-2022-01-10. :-)
However two points I wanted to mention:
- firstly (minor), the libraries/containers source is not clean (which explains why the tarball is so big)
- More serious: why was Win32 major bumped from 2.10 to 2.12? - this breaks foundation, hence current Stackage Nightly is kind of broken for Windows now: https://github.com/commercialhaskell/stackage/issues/6400
I can't really see any good way to resolve this in the short term.
Thanks, Jens
On Sun, 26 Dec 2021 at 04:23, Zubin Duggal
wrote: The GHC developers are very happy to at long last announce the availability of GHC 9.0.2. Binary distributions, source distributions, and documentation are available at the [usual place](https://downloads.haskell.org/ghc/9.0.2/).
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

- More serious: why was Win32 major bumped from 2.10 to 2.12? - this breaks foundation, hence current Stackage Nightly is kind of broken for Windows now: https://github.com/commercialhaskell/stackage/issues/6400
We needed to bump Win32 as per a request from the maintainer made at https://gitlab.haskell.org/ghc/ghc/-/issues/20017 Bumping it from 2.10.0 to 2.10.1.0 ran into https://github.com/haskell/win32/issues/174, which was fixed by https://github.com/haskell/win32/pull/175 Given this, our options at the time were: 1) Backport pull request #175 to 2.10.1 and wait for a new release of Win32 2) Revert https://github.com/haskell/win32/pull/160 in Win32 2.10, which is what caused WinIO/#174 3) Use Win32 2.12.0.1, which contains the requested fix(ghc/#20017), as well as the explicit exports added by #175, along with a few other minor changes from Win32 2.11 which I don't think are responsible for any of the pain discussed in the stackage issue. I made the decision to go with option 3 in the interests of getting the release out. However, if I understand correctly, we would still end up with the same problems as brought up in the stackage issue if we went with option 1. We might have avoided some of this pain if we went with option 2 and reverted the offending commits from WinIO 2.10 instead of using explicit import lists. But removing features from a major release of a library didn't seem like a good idea at a time, and would have delayed the 9.0.2 release even more. I hope this makes the reasoning for the decision clearer, and I do apologise for any pain caused. I did believe that under the circumstances bumping WinIO to 2.12.0.1 was the best way forward. Perhaps option 2 would have been better in retrospect, but at the time the benefits for such a change (in particular the regression in functionality) in a major release of Win32 were not so clear. Cheers, Zubin

I wrote WinIO a couple of times when I meant to type Win32. Sorry!
On 23 January 2022 1:32:15 pm IST, Zubin Duggal
- More serious: why was Win32 major bumped from 2.10 to 2.12? - this breaks foundation, hence current Stackage Nightly is kind of broken for Windows now: https://github.com/commercialhaskell/stackage/issues/6400
We needed to bump Win32 as per a request from the maintainer made at https://gitlab.haskell.org/ghc/ghc/-/issues/20017
Bumping it from 2.10.0 to 2.10.1.0 ran into https://github.com/haskell/win32/issues/174, which was fixed by https://github.com/haskell/win32/pull/175
Given this, our options at the time were:
1) Backport pull request #175 to 2.10.1 and wait for a new release of Win32
2) Revert https://github.com/haskell/win32/pull/160 in Win32 2.10, which is what caused WinIO/#174
3) Use Win32 2.12.0.1, which contains the requested fix(ghc/#20017), as well as the explicit exports added by #175, along with a few other minor changes from Win32 2.11 which I don't think are responsible for any of the pain discussed in the stackage issue.
I made the decision to go with option 3 in the interests of getting the release out.
However, if I understand correctly, we would still end up with the same problems as brought up in the stackage issue if we went with option 1.
We might have avoided some of this pain if we went with option 2 and reverted the offending commits from WinIO 2.10 instead of using explicit import lists. But removing features from a major release of a library didn't seem like a good idea at a time, and would have delayed the 9.0.2 release even more.
I hope this makes the reasoning for the decision clearer, and I do apologise for any pain caused. I did believe that under the circumstances bumping WinIO to 2.12.0.1 was the best way forward. Perhaps option 2 would have been better in retrospect, but at the time the benefits for such a change (in particular the regression in functionality) in a major release of Win32 were not so clear.
Cheers, Zubin _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
participants (4)
-
David Feuer
-
Jens Petersen
-
Zubin
-
Zubin Duggal