Add GHC 9.2 support for hie-compat #2003
Conversation
|
umm could both versions 9.0 and 9.2 use the same src dir? or would it need too much CPP? |
| {- | ||
| Forked from GHC v9.2.1 to work around the readFile side effect in mkHiefile | ||
|
|
There was a problem hiding this comment.
I may have asked this question before, but do we still need this fork?
GHC 9.0 and later include mkHieFileFromSource which no longer calls readFile, so maybe we can just drop the 9.0 fork and this one.
There was a problem hiding this comment.
I think I looked and the api was still slightly different but will check just to be sure
There was a problem hiding this comment.
are you still planning to check?
There was a problem hiding this comment.
Yep, sorry, will do so tomorrow!
There was a problem hiding this comment.
Ok, so both GHC 9.0 and 9.2 expose the function mkHieFileWithSource which we wrap in mkHieFile. The function mkHieFile itself from GHC 9.0 and 9.2 still perform side-effects.
However, I could not find a single consumer of the function mkHieFile (from hie-compat), so we can remove it completely?
We should be able to drop the source for GHC 9.2 and 9.0 and just rename the modules in the cabal file.
However, we should not do this, as when a module gets renamed in GHC, and we have for example this structure in the cabal file:
if impl(ghc >= 9.0) && impl(ghc < 9.4)
reexported-modules:
GHC.Iface.Ext.Types as Compat.HieTypes
if impl(ghc >= 9.4)
reexported-modules:
GHC.Iface.Hie.Types as Compat.HieTypes
cabal check will refute to upload such a .cabal description to Hackage as we re-export Compat.HieTypes twice, which is not allowed due to this cabal bug: haskell/cabal#4629.
To reduce maintainer burden, I think it is the best course of action to keep the source files but re-export immediately without custom logic.
- Rename
mkHieFiletomkHieFileWithSource(change API appropriately) - Keep source module such as
Compat.HieAstbut re-export functions without custom logic.
There was a problem hiding this comment.
Where do we use mkHieFile?
There was a problem hiding this comment.
Nowhere, not hls, not ghcide, not hiedb. Hackage reverse dependency lookup yielded only ghcide and hiedb as a result.
We are re-exporting in ghcide/src/Development/IDE/GHC/Compat.hs but as far as I can tell, only use the variant mkHieFile'
There was a problem hiding this comment.
So why don't we drop it and then it should become clear that we can hopefully drop hie-compat for GHC 9.x ?
There was a problem hiding this comment.
Dropped it and updated old versions to also drop it.
|
@jneira it would need some cpp, which we avoided so far in hie-compat. I thought it looked weird to share the sources and the code duplication is minimal, imo. |
fendor
force-pushed
the
ghc92-hie-compat
branch
2 times, most recently
from
77dbb73 to
f77e9e5
Compare
Then we can share the module re-exports for GHC >= 9
Just adds the same code as for 9.0 and fixes an import statement.