search

haskell / haskell-ide-engine

The engine for haskell ide-integration. Not an IDE
BSD 3-Clause "New" or "Revised" License
2.38k stars 210 forks source link

Supporting new versions of ghc (with slightly less hassle) #302

Closed robrix closed 7 years ago

robrix commented 7 years ago

I’ve spent some time this morning working on upgrading everything (cabal-helper, ghc-mod, ghc-mod-core, HaRe… everything) to work with ghc 8.2.1. I’m not done just yet, but I had a couple of thoughts that might make this sort of task easier in future, and I wanted to see whether you think they’d be worth doing or not.

  1. Use git submodules instead of git ref packages in stack.yaml.

    It’s inconvenient having to bump the SHA in stack.yaml, rebuild, wait for stack to fetch, etc., for every tweak to e.g. ghc-mod. Also, stack sometimes gets confused and you have to blow away ~/.stack-work/downloaded/ to sort things out.

    The workflow is a lot simpler when you have everything checked out directly, and I feel like that outweighs the inconvenience of having to occasionally git submodule update --init --recursive.

  2. Use record selectors to pattern match against GHC types.

    This mostly affects HaRePlugin.hs. A lot of ghc’s declaration constructors got fixities added to them in 8.2.1, which required adding a bunch of _s and will potentially also require CPP and #if __GLASGOW_HASKELL__ >= 802 guards to retain support for older ghc versions. Since getSymbols really only needs the tcdLName field, we could use the record selectors to get them out, e.g. by replacing this:

    go (TyClD (SynDecl n _ _ _ _)) = pure (J.SkClass,s n,Nothing)

    with this:

    go (TyClD (SynDecl { tcdLName = n })) = pure (J.SkClass,s n,Nothing)

    Realistically, this may or may not future-proof the project much since there’s countless ways ghc could change that would still invalidate this pattern match. (I haven’t looked at any past versions to see how unstable these datatypes & the record selectors are, either, tho that doesn’t necessarily predict future change.) But it would at least allow us to avoid CPP & a bunch of version-specific guards.

    Some of the dependencies, e.g. ghc-mod & HaRe, have a lot more to gain from this suggestion, so I might take this upstream as well.

Let me know what you think; if these changes would be welcome, I’ll be happy to see them through.

wz1000 commented 7 years ago

Sounds great! These changes would be very welcome. Thanks a lot for taking the time to work on this.

We hang out in #haskell-ide-engine on freenode, so you can drop in there any time.

I'm not sure about the git submodule change though, @alanz is better qualified to talk about that.

robrix commented 7 years ago

305 has been merged & per discussion in IRC @alanz prefers not to use submodules, so I’m going to close this out.