If this gets merged soon after the previous one so that there aren't intermediate commits, then okay I guess; but either way, please let's not have any more GHC upgrades for a year (or a couple years, given current pace of PS development?) at least. It really throws off the git rebase workflow when too many GHCs are needed to track down a bug.

let's not have any more GHC upgrades for a year

Agreed! I would have upgraded to 9.8 immediately, but HLS was broken there for quite some time and it wasn't clear if they were gonna fix it or just move on to 9.10. The good thing about 9.8 is that it's the current Stackage LTS version and the most up-to-date GHC that is not expected to get any further releases (https://endoflife.date/ghc). So this should be stable and serve us well for quite a while 👍

I think this PR is ready for review @rhendric and @purefunctor!

Thanks for your feedback @rhendric! I applied all your suggestions and it should be good to go now.

Thanks!

What about upgrading to GHC 9.10.2. That looks to be the current most stable release of GHC as of this May 2025.

#4574 (comment)

I'm trying to rebase to this version, and HLS (in VSCode/WSL) fails to run: Failed to find the GHC version of this Cabal project. Error when calling cabal exec -v0 -- ghc --print-libdir,

Executing cabal exec -v0 -- ghc --print-libdir gives an error:

Error: [Cabal-7107]
Could not resolve dependencies:
[__0] trying: cheapskate-0.1.1.2 (user goal)
[__1] trying: bytestring-0.12.1.0/installed-912b (dependency of cheapskate)
[__2] trying: xss-sanitize-0.3.7.1 (dependency of cheapskate)
[__3] next goal: attoparsec (dependency of xss-sanitize)
[__3] rejecting: attoparsec-0.14.4 (conflict: bytestring==0.12.1.0/installed-912b, attoparsec => bytestring<0.12)
[__3] skipping: attoparsec; 0.14.3, 0.14.2, 0.14.1, 0.13.2.5, 0.13.2.4, 0.13.2.3, 0.13.2.2, 0.13.2.1, 0.13.2.0, 0.13.1.0, 0.13.0.2, 0.13.0.1, 0.13.0.0, 0.12.1.6, 0.12.1.5, 0.12.1.4, 0.12.1.3, 0.12.1.2, 0.12.1.1, 0.12.1.0, 0.12.0.0, 0.11.3.4, 0.11.3.3, 0.11.3.2, 0.11.3.1, 0.11.3.0, 0.11.2.1, 0.11.1.0, 0.10.4.0, 0.10.3.0, 0.10.2.0, 0.10.1.1, 0.10.1.0, 0.10.0.3, 0.10.0.2, 0.10.0.1, 0.10.0.0 (has the same characteristics that caused the previous version to fail: excludes 'bytestring' version 0.12.1.0)
[__3] rejecting: attoparsec-0.9.1.2 (conflict: xss-sanitize => attoparsec>=0.10.0.3 && <1)
[__3] skipping: attoparsec; 0.9.1.1, 0.9.0.0, 0.8.6.1, 0.8.6.0, 0.8.5.3, 0.8.5.2, 0.8.5.1, 0.8.5.0, 0.8.4.0, 0.8.3.0, 0.8.2.0, 0.8.1.1, 0.8.1.0, 0.8.0.2, 0.8.0.1, 0.8.0.0, 0.7.2, 0.7.1, 0.6, 0.5.1, 0.5, 0.4 (has the same characteristics that caused the previous version to fail: excluded by constraint '>=0.10.0.3 && <1' from 'xss-sanitize')
[__3] fail (backjumping, conflict set: attoparsec, bytestring, xss-sanitize)
After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: base, bytestring, unix, xss-sanitize, attoparsec, network, filepath, exceptions, stm, attoparsec-text, cheapskate
Try running with --minimize-conflict-set to improve the error message.

Has anyone run HSL successfully on this upgrade?

It’s working with HLS for me, but I first had to fully purge all dependency and build files so they are build correctly with the new version!

It’s working with HLS for me, but I first had to fully purge all dependency and build files so they are build correctly with the new version!

What do you mean by purging all dependencies? So far I tried to stack clean, removing .stack-work, then stack build.

I wonder why it is saying rejecting: attoparsec-0.14.4 (conflict: bytestring==0.12.1.0/installed-912b, attoparsec => bytestring<0.12) if attoparsec-0.14.4 has bytestring (<13) dependency

After cabal/stack update and stack purge/build this version mismatch error gone, and another:

Error: [Cabal-7107]
Could not resolve dependencies:
[__0] trying: cheapskate-0.1.1.2 (user goal)
[__1] trying: base-4.19.2.0/installed-9fbd (dependency of cheapskate)
[__2] trying: purescript-0.15.15 (user goal)
[__3] next goal: haskeline (dependency of purescript)
[__3] rejecting: haskeline-0.8.2.1/installed-0eda (conflict: purescript => haskeline==0.8.2)
[__3] skipping: haskeline; 0.8.3.0, 0.8.2.1 (has the same characteristics that caused the previous version to fail: excluded by constraint '==0.8.2' from 'purescript')
[__3] rejecting: haskeline-0.8.2 (conflict: base==4.19.2.0/installed-9fbd, haskeline => base>=4.9 && <4.18)
[__3] skipping: haskeline; 0.8.1.3, 0.8.1.2, 0.8.1.1, 0.8.1.0, 0.8.0.1, 0.8.0.0, 0.7.5.0, 0.7.4.3, 0.7.4.2, 0.7.4.1, 0.7.4.0, 0.7.3.1, 0.7.3.0, 0.7.2.3, 0.7.2.2, 0.7.2.1, 0.7.2.0, 0.7.1.3, 0.7.1.2, 0.7.1.1, 0.7.1.0, 0.7.0.3, 0.7.0.2, 0.7.0.1, 0.7.0.0, 0.6.4.7, 0.6.4.6, 0.6.4.5, 0.6.4.4, 0.6.4.3, 0.6.4.2, 0.6.4.1, 0.6.4.0, 0.6.3.2, 0.6.3.1, 0.6.3, 0.6.2.4, 0.6.2.3, 0.6.2.2, 0.6.2.1, 0.6.2 (has the same characteristics that caused the previous version to fail: excludes 'base' version 4.19.2.0)
[__3] rejecting: haskeline-0.6.1.6 (conflict: purescript => haskeline==0.8.2)
[__3] skipping: haskeline; 0.6.1.5, 0.6.1.3, 0.6.1.2, 0.6.1.1, 0.6.1, 0.6.0.1, 0.6, 0.5.0.1, 0.5, 0.4, 0.3.2, 0.3.1, 0.3, 0.2.1, 0.2 (has the same characteristics that caused the previous version to fail: excluded by constraint '==0.8.2' from 'purescript')
[__3] fail (backjumping, conflict set: base, haskeline, purescript)
After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: purescript, base, haskeline, cheapskate

In purescript.cabal changed haskeline==0.8.2 to haskeline >= 0.8.2 && < 0.8.3, then it worked.

In stack.yaml extra-deps contains - haskeline-0.8.2, and probably because allow-newer-deps in may install 0.8.2.1 from Stackage

So perhaps something should be done about it.

I first mentioned the Cabal breakage in #4568 (review) and if I recall correctly, using 0.8.2.1 causes the built binary to be built with libtinfo which makes pre-built binaries harder to distribute.

You can update the version bounds for now for local development or maybe use hie.yaml to tell HLS to use stack

I first mentioned the Cabal breakage in #4568 (review) and if I recall correctly, using 0.8.2.1 causes the built binary to be built with libtinfo which makes pre-built binaries harder to distribute.

For clarification, why it it installs 0.8.2.1 if 0.8.2 is required and restricted? And how it is going to be fixed?

You can update the version bounds for now for local development or maybe use hie.yaml to tell HLS to use stack

Btw I added hie.yaml with just cradle: stack:, HLS it doesn't work normally.

• First it errors GHC ABIs don't match, solved it by adding system-ghc: true into stack.yaml
• but after this it startes, but shows (GhcSession,NormalizedFilePath "/code/purescript/...") cannot satisfy -package all (use -v for more information)compiler error.

Also I have troubles with running HSL on tests/* modules, if src/* and app/* works, tests/* modules give the error on top of the files :Failed to run ["cabal","v2-repl","/code/purescript/.worktrees/make-cutoff/tests/TestInteractive.hs"] Have you met such issue, any recommendations?

UPD: managed to make HLS work in tests/* by adding tests: True in cabal.project.

I think you might have to run stack build once, but afterwards it should work without any additional config files/changes. (At least it does for me…)

After setting up ghcup and stack integration HLS started to work fine.