GHC 9.8.3 is now available

Announcements
#1

The GHC developers are happy to announce the availability of GHC 9.8.3. Binary
distributions, source distributions, and documentation are available on the
release page.

This release is primarily a bugfix release the 9.8 series. These
include:

  • Significantly improve performance of code loading via dynamic linking (#23415)
  • Fix a variety of miscompilations involving sub-word-size FFI arguments
    (#25018, #24314)
  • Fix a rare miscompilation by the x86 native code generator (#24507)
  • Improve runtime performance of some applications of runRW# (#25055)
  • Reduce fragmentation when using the non-moving garbage collector (#23340)
  • Fix source links in Haddock’s hyperlinked sources output (#24086)

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.

Happy compiling!

  • Ben
36 Likes
Haskell Foundation October 2024 Update
#2

I have updated Stack’s default setup-info dictionary for these binary distributions, and added GHC 9.8.3’s global hints to global-hints.yaml.

1 Like
#3

Thank you for the 9.8.3 release - that should un(b)lock Stackage LTS 23 :tada:

Stackage Nightly 2024-10-22 (ghc-9.8.3) :: Stackage Server is now on ghc-9.8.3

Unfortunately a few packages had to be disabled: see changes.

The main points I noticed while updating: filepath was not bumped (so 9.8.3 is behind 9.6.6) and Unit import ambiguity broke a few packages.

In other news I am also updating Fedora ghc9.8.

#4

As a maintainer of 4 core libraries, I have to say the GHC release process is intransparent and the communication lacking.

I have no idea what versions of my packages land in which GHC release.

As GHCup maintainer, I have almost zero knowledge about GHC releases too.

If GHC HQ expects me and others to listen to mailing lists, then I’m afraid I don’t have the time.

Please start coordinating releases properly.

1 Like
#5

Could you say what this means? Sounds like something I should make a 9.8.3 breakage inventory for.

#6

The 3 affected packages were ghc-lib-parser, dimensional, generic-arbitrary

#7

Ah, I see, thanks. It’s because Unit became an export from Control.Deepseq 1.5.1.0.

#8

Ah okay thanks - maybe the impact is not so high, but let’s see.

#9

Mailing lists seem fine, but I do think it would be nice to know what happened to filepath.

#10

I’m afraid not.

It has been that way for a while that some groups have to watch GHC development and releases (including CLC… figuring out if base MRs were merged/released/mis-implemented or API got accidentally broken, etc.).

A proper release process would contact the involved parties, have a clear process and publicly visible documentation of what is going to happen and when.

Right now I either have to be actively involved in release matters or watch mailing lists, issues trackers and have weekly calls with GHC devs. Again: that is not a sustainable strategy to deal with volunteers time.

I sometimes get a ping on the core libraries I maintain that says: “we need a tag” and that’s all the information there is. I can then go and make assumptions or conclusions about why and what. Example: Missing tags (for 0.1.4 etc). · Issue #28 · haskell/file-io · GitHub

#11

It sounds like the problem isn’t that mailing lists (or its successor, Discourse) are used. The problem is they are not used.

I suppose there’s information you would like to get that you aren’t getting. What information is that, exactly? Is it the version number of libraries that will be included in a release?

#12

A minor 9.6 and 9.8 release were cut using some filepath version (1.4.200 I believe)

GHC’s master branch was updated to higher major version 1.5.0.0

Date:   Tue Jan 23 12:44:38 2024 -0500
Bump filepath to 1.5.0.0

In preparation for the 9.6 release the filepath version on the 9.6 branch was updated to 1.4.300.1

Date:   Fri Mar 22 14:11:31 2024 +0530

    Bump filepath submodule to 1.4.300.1

Usually backports are done by ensuring changes are on master first and then backporting them. Here that would have meant doing a breaking change for a boot library in a minor ghc version. Which we like to avoid. So instead the version of file path was only updated on the ghc-9.6 branch.

This meant there wasn’t a natural MR to backport for the 9.8.3 release and we failed to bump the filepath version.

To prevent this in the future we will add a check to the release checklist that ensures that for any release ghc-A.B.C boot library versions should not be older than for the latest ghc-A.B-1 release at the time of release.

E.g. for release 9.8.3 we would have check that library versions are equal or higher than what is in the latest 9.6 release and this would have prevented this bug.

It’s quite unfortunate that this has happened, but given that it’s a minor version difference I hope it will not cause too much breakage.

Note that such a check still can’t guarantee that moving to a higher major ghc version will never result in an older boot library.

For example should we release ghc-9.6.7 in a few months we might reasonably upgrade a boot library to a versions newer than the ones 9.8.3 shipped with.

3 Likes
#13

This is just a manifestation of a broader issue and adding more tests will not fix it.

I don’t have the impression that the release process is user or stakeholder focussed. It’s developer focussed.

Sure, you can just see yourself as an independent distributor of some core libraries and don’t really have to talk or coordinate with anyone.

The same goes for the consumers of your bindists.

But I’m not sure that’s a good strategy.

Ben did start a document some time ago afair, outlining the specific versions of all core libraries that will be included. I don’t remember anymore where, because it was on a mailing list I wasn’t subscribed to and I couldn’t reply.

I don’t know what happened to it and this is just one of the things I would expect from a user/stakeholder centric release process.

3 Likes
#14

That will be good, thanks :+1:

(For example it caused stack to be dropped from current Stackage Nightly and likely Stackage LTS 23. On the plus side we now have cabal-install again…)

1 Like
#15

Would it be possible to update the version-history document with the versions for 9.8.3? I consult this page for almost every upgrade to see what has changed. Of course, it is possible to get to this information, but I thought it would be nice to either update that page, or maybe deprecate it entirely if I am the only one using it.

6 Likes
#16

I also look at that page often.

2 Likes
#17

I’ve been using snoyman/base and, if in need of other boot library versions, going to look these up in the GHC users guide§release notes#included-libraries. Great to see all these versions in one place.

2 Likes
#18

Updating that page is on the release checklist, but like any manual process it is prone to human error. I think Ben took a break after the release was finished (understandable, it’s a lot of frustrating work), and I imagine it’ll get fixed up when he returns.

#19

Can you clarify if this was a bounds issue or is stack simply not buildable or otherwise broken with this version of filepath? Either is regrettable but the later would still be worse. I briefly checked the stack issue tracker but couldn’t find a ticket that seemed relevant.

#20

Stack builds fine with GHC 9.8.3. (EDIT: That is, to be clear, the executable stack can be built from its package using GHC 9.8.3.)