Add GHC 9.2 support for hie-compat

[fendor]

Just adds the same code as for 9.0 and fixes an import statement.

[jneira]

umm could both versions 9.0 and 9.2 use the same src dir? or would it need too much CPP?

[pepeiborra]

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.

[fendor]

I think I looked and the api was still slightly different but will check just to be sure

[pepeiborra]

are you still planning to check?

[fendor]

Yep, sorry, will do so tomorrow!

[fendor]

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 mkHieFile to mkHieFileWithSource (change API appropriately)
• Keep source module such as Compat.HieAst but re-export functions without custom logic.

[pepeiborra]

Where do we use mkHieFile?

[fendor]

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'

[pepeiborra]

So why don't we drop it and then it should become clear that we can hopefully drop hie-compat for GHC 9.x ?

[fendor]

Dropped it and updated old versions to also drop it.

[fendor]

@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.

[pepeiborra]

Thanks!!