Open cumber opened 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:
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 ahie-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.