haskell / haskell-language-server

Official haskell ide support via language server (LSP). Successor of ghcide & haskell-ide-engine.
Apache License 2.0
2.72k stars 367 forks source link

hie-compat 0.3.1.2 stops older versions of haskell-language-server building on GHC 8.10 #3907

Open cumber opened 11 months ago

cumber commented 11 months ago

The changelog for Haskell Language Server says that support for GHC 8.10 was dropped in version 2.3.0.0. So 2.2 should still support GHC 8.10.

Unfortunately, haskell-language-server depends (via ghcide among others) on hie-compat, and when support for GHC 8.10 was dropped from hie-compat it appears to have been done with only a patch-level version bump (0.3.1.1 -> 0.3.1.2), and by simply removing the conditionally-included source folder that supports GHC 8.10, without changing any version bounds that would cause Cabal to reject this version when solving for GHC 8.10.

This means that when I try building haskell-language-server 2.2.0.0 with GHC 8.10, it now selects hie-compat-0.3.1.2 for the build plan and then when it gets to building hie-compat it fails with Error: Setup: can't find source for Compat/HieAst in ., dist/build/autogen. If I manually add a hie-compat < 0.3.1.2 constraint, then building haskell-language-server succeeeds.

I think we need some hackage revisions. Would setting hie-compat-0.3.1.2 to have bounds on base matching the GHC versions it actually supports be sufficient? Or do we need revisions of the last 8.10-supporting versions of packages that depend on hie-compat, with tighter upper bounds to exclude 0.3.1.2?

Steps to reproduce

Build haskell-language-server 2.2.0.0 with GHC 8.10.

Expected behaviour

Cabal selects hie-compat 0.3.1.1, and the build succeeds.

Actual behaviour

Cabal selects hie-compat 0.3.1.2, and the build fails.

michaelpj commented 11 months ago

Yes, that shouldn't have been a patch-level bump.

I think we need some hackage revisions. Would setting hie-compat-0.3.1.2 to have bounds on base matching the GHC versions it actually supports be sufficient?

That seems reasonable to me. Or possibly adding an if impl (ghc < 9.0) buildable: False stanza might do it? That seems nicer since it directly conditions on the GHC version rather than indirectly via base. I don't know if that will persuade cabal to pick the the older version, though :thinking: