ghc-modi check not consistent

rikvdkleij commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

@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 commented 10 years ago

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