'stack ghci' doesn't notice that a module got deleted

[borsboom]

If you remove a module and then run stack ghci before stack build, it fails with a Could not find module error.

Hypothesis:

The build doesn't run before stack ghci reads the modules, so it doesn't get a chance to re-write the .dump-hi files with the updated information (that the module does not exist), so stack ghci is still reading the out-of-date information.

Notes from @chrisdone:

as a heads up the stack ghci code uses the build info, but runs the equiv. of stack build —only-dependencies to ensure that dependencies are available
at a guess, it seems that the build cache doesn’t get invalidated by simply reading it in the manner that stack ghci does, but i didn’t get niklas to test with stack build to see if running that would trigger a cache invalidation
the building with —only-dependencies was enabled to avoid ghci not being able to start when there’s a build error. i don’t like that fix, i’d prefer if the build just ran and if it fails then it should catch the exception and print the compile error but still launch ghci anyway in an optimistic way (edited)

It's likely that fixing #1065 will also fix this, but tracking separately since the symptoms are different.

(PAT-125)

[chreekat]

In general stack ghci doesn't seem to like it when modules come and go. I often get "panic: the "impossible" happened!" when stack ghci is running and I try adding or deleting modules.

Maybe that's to be expected (? I don't know how stack ghci interacts with cabal really) but it's still annoying.

[borsboom]

@chreekat is that Stack-specific? As I understand it (but I'm not much of a GHCi user), once you're actually in the GHCi interpreter, Stack has fully passed control to it and is no longer involved at all.

This particular issue was about the list of modules that was passed to GHCi on startup, and should now be fixed on master.

[chreekat]

@borsboom probably not stack-specific, in fact. :)