GHC 9.8.3 is now available

Announcements
21

The newest stack-3.1.1 has dependency constraint: >= 1.4.300.1, so it gets booted from the nightly.

22

Sorry. I forgot that when a Stack release is uploaded to Hackage, that is done with stack upload . --pvp-bounds=lower, which adds lower bounds that don’t exist in the package description in the master branch version of Stack. So, Stack 3.1.1 (built with Stackage LTS 22.28, GHC 9.6.6) has filepath >= 1.4.300.1.

EDIT: I’ve published a Hackage revision for stack-3.1.1 which relaxes the lower bound on filepath to accommodate the boot package of GHC 9.8.3.

3 Likes
23

Thanks, so stack is back in Stackage Nightly now (thanks also to Andreas Ländle) :tada:

3 Likes
24

I’m most looking forward to the GHCi reloading speed improvement #23415: GHCi is slow on first :main · Issues · Glasgow Haskell Compiler / GHC · GitLab which does affect Linux (for play), but on macOS (for pay) it is agonizingly slow at reloading on a big project.

5 Likes
25

I don’t know anything about it, but in case in helps, I found that using :set -fobject-code make reloading (my) big projects much faster .

3 Likes
26

I think GHCup will skip this release and wait for 9.8.4.

Although that would be the first time it happens, that is well within the decision scope of distributors.

You can still get all the versions from the vanilla channel. But keep in mind they receive zero QA from GHCup and a large number of them are broken (e.g. due to a build system bug).

27

This bug isn’t about the object files vs bytecode, which does provide a speed boost for that part of the pipeline, but this is about after the modules are all loaded. Even if it only reloaded one module. You try to evaluate anything and then GHCi hangs for a while before even starting the eval. It’s a heinous issue on macOS. Absolutely slows your iteration cycle to a crawl.

So this being fixed is very exciting. :clap::clap:

3 Likes
28

Oh, I have noticed that on Linux! I wondered what was happening with a weird initial slow down.

3 Likes
29

Same here (on mac). It has been “just something to live with” for years. Excited to try 9.8.3 or the next 9.10 release.

30

9.8.3 contains some important correctness fixes over 9.8.2 so I would encourage anyone using 9.8 to upgrade to 9.8.3 if they can.

I think GHCup will skip this release and wait for 9.8.4 .
Although that would be the first time it happens, that is well within the decision scope of distributors.

I don’t know if this will affect ghcup’s plans but at this point a 9.8.4 release will only be planned if new serious issues are discovered.

I can see that the tracking ticket could be seen as an indicator of a planned 9.8.4 release but it exists primarily to track the steps needed/taken if a given release happens. It does not guarantee that there will be a 9.8.4.

31

Then the only way for GHCup is to fix the filepath packaging issue downstream.

That opens nasty issues though:

  • if I fix it in-place for 9.8.3, then users may get subtle surprises when they switch between, say, stack and ghcup, because they ship slightly different GHCs
  • if I fix it in a properly new version, I now made up a version out of thin air

Why does GHC HQ not see it as a pressing issue to create a follow up release?

2 Likes
32

For my benefit, may I clarify: is the " filepath packaging issue " a reference to the fact that GHC 9.8.3 has the same boot library version as GHC 9.8.2? (EDIT: … and so misses the fix of the splitFileName bug on Windows, introduced in filename-1.4.300.1?)

The reason I ask is that a Stackage snapshot does not include directly GHC boot packages (it only specifies a version of GHC). So, if different versions of ‘GHC 9.8.3’ (for the same platform) were to come with different versions of boot package filepath, that would damage a snapshot’s promise of ‘reproducible builds’.

1 Like
33

Why does GHC HQ not see it as a pressing issue to create a follow up release?

As I understand it the “filepath packaging issue” is:

Is there more to it or is that a fair characterization?

34

Yes.

FilePath bugs are security relevant. If filepath input isn’t properly guarded/sanitized, you may be able to DoS a backend/system or compromise data. It is impossible to know how users exactly use primitives like splitFileName, but it is very possible that this can lead to severe production bugs.

4 Likes
35

I understand that you might want to recommend 9.6.6 instead of 9.8.3 for this reason (well, if there aren’t more serious sec flaws in 9.6.6), but how does it help to promote 9.8.2 instead of 9.8.3?

1 Like
36

I am not promoting 9.8.2.

There are only two options (as I already explained elsewhere):

  1. 9.8.4 is released by GHC HQ to fix this (it doesn’t appear that will happen, at least not in a timely manner)
  2. 9.8.3 is fixed downstream by GHCup

I am not going to ship 9.8.3 as-is.

3 Likes
37

Does 9.8.2 as distributed by GHCup include a downstream fix?

38

No, although the bug was fixed a month before the 9.8.2. release.

I have not kept up with the exact boot library versions of every GHC release, but that is likely going to change now.

39

In that case, if the file path issue is a blocker for shipping 9.8.3 as is, shouldn’t 9.8.1–9.8.2 be deprecated, hidden, or removed in GHCup, as having a critical bug?

40

Yes, we’re lacking proper mechanisms for that. See:

Technically, GHCup allows arbitrary ‘tags’ in the metadata, so I could just add broken to 9.8.2. But existing users won’t really see that, unless they regularly stare at the ghcup TUI.

3 Likes