ghc-modi check not consistent

[rikvdkleij]

ghc-modi version 4.1.3

I noticed in this project some inconsistent behavior of ghc-modi (ghc-mod is doing fine):
https://github.com/rikvdkleij/Quicksort

To describe how to reproduce is difficult because it's not predictable. Try something like this:
1 - Make a syntax error in src/Quicksort.hs by removing space between module and Quicksort on first line (ghc-modi gives "parse error on input 'where'").
2 - Check test/QuicksortSpec.hs, ghc-modi gives "File name does not match module........".
3 - Go back to src/Quicksort.hs. Fix it and check it.
4 - Check test/QuicksortSpec.hs.
5 - Repeat step 1. Now same error appears as for test/QuicksortSpec.hs in 2. (ghc-mod stil gives parse error)

Hope this helps.

Regards,
Rik

[rikvdkleij]

I noticed it again with different files and different syntax error. It seems like last error is "hanging". Also restarting ghc-modi does not help.

[rikvdkleij]

Is this expected behavior of ghc-modi:
check src/Quicksort.hs
src/Quicksort.hs:11:1:Parse error: naked expression at top levelPerhaps you intended to use TemplateHaskell
OK
check src/Filter.hs
src/Quicksort.hs:11:1:Parse error: naked expression at top levelPerhaps you intended to use TemplateHaskell
OK

[int3]

I've experienced a similar issue. It seems that ghc-modi doesn't show errors if a file is checked repeatedly unless its mtime changes between checks. And it also has a tendency to return unrelated results from old requests -- but only if the mtime of the files from the old request have changed.

[kazu-yamamoto]

ghc-modi uses cache. If mtime of a file is not changed, ghc-modi does not read it again. That's why ghc-modi is much faster than ghc-mod.

Emacs front-end modifies mtime of a target file before asking ghc-modi to check.

[kazu-yamamoto]

See: http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.8.3/GHC.html#v:load

"This function implements the core of GHC's --make mode. It preprocesses, compiles and loads the specified modules, avoiding re-compilation wherever possible."

[int3]

If ghc-modi is doing caching, then shouldn't it return the same errors for a file until its mtime gets updated? I'm saying that it's not returning any errors at all on subsequent checks. Specifically:

> check Foo.hs
Error: Foo.hs line 1 column 6 ...
> check Foo.hs
(nothing) -- I'd expected `Error: Foo.hs line 1 column 6 ...`

Also,

> check Foo.hs
Error: Foo.hs line 1 column 6 ...
> check Foo.hs
(nothing)
-- now, we update the `mtime` of Foo.hs.
> check Bar.hs
Error: Foo.hs line 1 column 6 ...
-- note that Bar.hs does not import Foo.hs

Let me know if you can't reproduce this, I can set up a full test case. My description above is from memory, but I'm pretty sure it's accurate.

[kazu-yamamoto]

You are right. The master branch now implements GhcMod monad. So, we can now have a state. Probably, we need to record mtime and errors in the state.

[rikvdkleij]

@kazu-yamamoto Can you give some estimation when you have fixed this issue? I have not (yet) enough Haskell experience to fix this issue. I would like to help with testing.

[kazu-yamamoto]

I'm waiting that @DanielG implements ErrorT stuff. #292

[DanielG]

Oh sorry I didn't know you were waiting on me otherwise I would've pushed this stuff sooner.

[rikvdkleij]

I noticed same behavior with info in ghc-modi.

[DanielG]

IIRC this should be fixed now @kazu-yamamoto removed the caching stuff from ghc-modi and the changes should have landed in 5.2.0.0 @rikvdkleij does this problem still happen with ghc-mod >= 5.2.0.0?