Panic on "plusProv" with recursive modules

[lukemaurer]

Recursive modules seem to cause trouble with ghc-mod info and ghc-mod type.

rec-mods.zip

This is a very minimal example of two mutually recursive modules (they both even have empty export and import lists).

luke@velvetspoon rec-mods $ ghc-mod info Even.hs f
EXCEPTION: info:
               ghc-mod: panic! (the 'impossible' happened)
                 (GHC version 7.8.4 for x86_64-unknown-linux):
                plusProv

             Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Cannot show info

ghc-mod type still works for this one, but not for this variation:

rec-mods-2.zip

This one simply adds:

data Nat

f :: Nat
f = undefined

Now ghc-mod type Even.hs 8 1 (or any other column number) gives the same crash.

(Notably, GHC's plusProv function, defined in RdrName.lhs, has a comment describing an “obscure bug lurking here” involving recursive modules.)

This is GHC 7.8.4 and ghc-mod 5.4.0.0.

[DanielG]

I'm not sure what can be done about this if anything. If it's a bug in GHC there's not much we can do other than adding a workaround. I have the impression that hs-boot modules are, for good reason, considered something you should never ever ever use if you can help it and this is just a symptom of that attitude.

Anyways I don't have time to go digging though ghc to find out where we even call that function from but I can give you some guidance on constructing a testcase that takes ghc-mod out of the equation to see if it is a bug in GHC or in how ghc-mod uses it.

[lukemaurer]

Well, this bug keeps ghc-mod from working with GHC itself, which uses .hs-boot files extensively. Also, I suspect that it's frowned upon because it's ill-supported more than vice versa. (Every way I can think of to refactor away my recursive modules either makes things seven times uglier, destroys modularity, or requires orphan instances.)

But I digress. The rec-mods.zip code compiles fine with GHC (and passes ghc-mod check as well), as does my original project that first ran into the problem. (And of course GHC compiles, too!) Is there something more I should add to make it a proper test case?

[DanielG]

I see your point but hs-boot being ill supported is exactly what I meant as we can see here where GHC itself doesn't support them properly ;)

Anyways I'm all for improving the situation so as far as the testcase goes I was thinking more of a module using the GHC API directly also exhibiting this panic with the code you posted so we can report this bug upstream in GHC.

As I said I don't have all that much time to spare right now and this issue is fairly low priority since only a small number of users are going to run into it at all (I could be wrong of course), so if you have some time to track this down we can work on something like this: https://github.com/DanielG/ghc-mod/blob/master/test/manual/not-interpreted-error/GhcTestcase.hs which we can demonstrate the problem with.

[lukemaurer]

I think I found the proximate cause: withInteractiveContext adds the whole module graph to the context, including the .hs-boot modules. I think we'd want to filter out those somehow, but it's not immediately obvious how. Anyway, this test case gives me the plusProv crash (run inside the rec-mods.zip directory):

GhcTestcase.hs.txt

[DanielG]

You might also want to test HomeModuleGraph (https://github.com/DanielG/ghc-mod/blob/master/Language/Haskell/GhcMod/HomeModuleGraph.hs#L148) because it probably ignores hs-boot moules but I'm not sure if that's actually true. The code in there is mostly modeled on GHC's Finder module so that should be useful to compare against.