All-Red after creation of new module with inconsistent name

[laura-dietz]

While I think there are multiple issues that are visible in the issue below, the main problem is that ghcide is not trying to recompile the all-red file even after the bug is fixed. This was also getting in my way on other occasions, where there was a mistake in a different component that the all-red file was relying on.

---

I commonly run into "all red" issues when I create a new module with disagreeing filename and the module name.

Sure, this is 100% my fault -- but it would be great to get an error message such as "module name and filename disagree".

The actual faulty line (the module statement in the new file), is not marked as faulty.

Instead I get all-reds in a large number of source files, and one of the following cryptic error messages:

Failed to parse result of calling cabal
Resolving dependencies...
[...]
[scroll several pages down]

[...]
 File name does not match module name:

Or (if I was messing with the hie.yaml file)

AesonException "Error in $.cradle: Expected an object with path and component keys"

(this error message persists even if I revert the hie.yaml file to its original state)

Even when I fix my mistake, the all-reds and error messages persist. It is as if ghcide would have given up on trying to compile my code. (see screenshot below) At this point only killall ghcide seems to reset things.

My interpretation is that since ghcide has never seen the new module, it does not know which source file to blame --- although cabal's error message is pretty clear.

Ghcide version 0.2.0 (commit 4149ab5)
GHC version ghc-8.8.3.20200530 (custom version with allred fix)

[laura-dietz]

Instructions to reproduce:

1. Use existing compiling project
2. create new module file (say ModuleX.hs) but include a faulty line module ModuleY where to ModuleX)
3. Take some existing functions, move to ModuleX / import ModuleX in originating source file
4. add ModuleX to cabal file library/exposed-modules
5. watch.
6. Fix faulty line in ModuleX.hs to module ModuleX where
7. problem persists

[pepeiborra]

Thanks for opening this issue!

I think there's more than one thing going on here:

1. The behavior after a failure loading a cradle. I would expect that ghcide would retry to load it once the cradle is modified, but it sounds like it doesn't.

2. The reporting of module-wide errors, which results in all-red editors. I think this should already work better in HEAD since Use a better noRange ghcide#612

3. The garbage collection of diagnostics after the object they were attached to disappears (renamed/deleted). I don't think ghcide ever removes diagnostics, but maybe the lsp-client would.

BTW If/when ghcide gets stuck, the least painful way to reset it is by using the VSCode "Restart extension host" command.

[pepeiborra]

Given that 1 is separately reported in #757, 2 is fixed, and there is an older ticket for 3 somewhere, I'm going to close this issue