Code action for new GHC module structure

[alanz]

GHC 9.0 moves modules around, so we have to do things like

#if __GLASGOW_HASKELL__ >= 900
import qualified GHC.Data.Bag          as GHC
import qualified GHC.Driver.Session    as GHC
import qualified GHC.Data.FastString   as GHC
import qualified GHC.Types.Name        as GHC
import qualified GHC.Types.Name.Set    as GHC
import qualified GHC.Utils.Outputable  as GHC
import qualified GHC.Types.Name.Reader as GHC
import qualified GHC.Types.SrcLoc      as GHC
import qualified GHC.Types.Var         as GHC
import qualified GHC.Types.Name.Occurrence as OccName (OccName(..),occNameString,pprNameSpaceBrief)
#else
import qualified Bag            as GHC
import qualified DynFlags       as GHC
import qualified FastString     as GHC
import qualified Name           as GHC
import qualified NameSet        as GHC
import qualified Outputable     as GHC
import qualified RdrName        as GHC
import qualified SrcLoc         as GHC
import qualified Var            as GHC
import qualified OccName(OccName(..),occNameString,pprNameSpaceBrief)
#endif 

Perhaps we could make a code action for this, when running GHC 9.0. Probably just to change the single line, rather than a whole CPP thing.

[wz1000]

See https://github.com/hsyl20/ghc-api-compat

[alanz]

@wz1000 thanks, but that is to some extent just kicking the can down the road. I would rather reverse that mapping, and migrate the old names to the new in source.

[wz1000]

I think it would be simpler to use the compat package and reverse the mapping when we drop support for ghc 8.x

Otherwise we will have to maintain both versions.

[jneira]

we still think that we should add this code action?

[alanz]

I see it is still moving around on master.

But I do think it may be useful, once a GHC embodying these changes comes out.

[Anton-Latukha]

(2 years down the line): GHC still shifts things around. HLS now uses an internal Compat module system, it is ~50% there. & instead of reversing the module API, it has its own minimalistic grouping of changes. Having it centralized internally quite simplified the situation. Now there are thought to eventually form a separate package from the Compat subtree #2454.

[michaelpj]

I think we've settled on doing this with compat modules, and adding code actions is a bit heavyweight, so I'm going to close this for now.