Warnings disappear after saving a buffer

[zarybnicky]

Hi,

I've tried using Dante (in combination with reflex-platform through a custom dante-repl-command-line going through nix-shell). Everything works fine, with one exception - after I save a file, flycheck triggers and all warnings disappear. If the file doesn't compile and has some errors, they stay visible.

I don't have the elisp knowledge to debug it all the way (or the time to learn right now), but I've managed to trace it down to https://github.com/jyp/dante/blob/master/dante.el#L350.

If I replace :buffer (when (string= temp-file file) buffer) with simply :buffer buffer, the warnings stay visible after saving as well.

That has solved my problem for now and I'm currently long past my bedtime, so I'll just leave this here in case I forget about it tomorrow. Next step would be to learn how debug elisp properly instead of just reading through flycheck and dante code randomly :)

[zarybnicky]

Ok, I take it back - that change just made it so that the warnings don't disappear if I save the file immediately after some changes, which they did before... So I'm back to 'no idea where the problem is'. I guess I can work around it by not saving the file immediately after some changes, which I do by reflex now after some unpleasant experiences with crashing APL environments.

[purcell]

This is likely the same issue that intero had to work around: if you load the same file twice in ghci, and it has warnings but not errors, ghci does not report the the warnings the second time it is loaded.

[zarybnicky]

Thanks for the info. Yes, I've found https://github.com/ commercialhaskell/intero/issues/143, now all I need to do is to port it to Dante. I'll probably get to it during the weekend, I'll see what I can do then.

…

On Wed, Nov 15, 2017 at 7:36 AM, Steve Purcell ***@***.***> wrote: This is likely the same issue that intero had to work around: if you load the same file twice in ghci, and it has warnings but not errors, ghci does not report the the warnings the second time it is loaded. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#52 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE7AYUPN3UdWWCPDyd8sI5d9TJGd8P5kks5s2oaGgaJpZM4Qaqqd> .

[purcell]

@zarybnicky We subsequently changed the code for that, so be sure to check out how it works in the latest intero. It's unfortunate that it adds some complexity.

[jyp]

As often, I would recommend bringing this issue to the attention of the GHCi maintainers.
Furthermore, the speed of the checker would be impacted by doing anything else than a simple reload. (And in general I hate increasing the complexity just to work around upstream issues.)

[chrisdone]

The reliable fix is here: chrisdone-archive/intero#468

GHCi doesn't report warnings because you changed the file too rapidly, below <1 second duration. So in reporting whatever the last warnings were, if your users make a change too rapidly, then it'll report warnings for old code. I had this situation in Intero. The change in 62c3057 will report incorrect warnings sometimes.

[jyp]

@chrisdone This does not seem to happen with my setup. What is the sequence of steps to reproduce the bug?

[chrisdone]

It's GHCi behavior:

bash-3.2$ cat > input.txt
:set -Wall -fobject-code
:!echo "x = 'a'" > x.hs
:l x.hs
:!echo "y = 'a'" > x.hs
:l x.hs
:q
bash-3.2$ cat input.txt | ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/  :? for help
Prelude> Prelude> Prelude> [1 of 1] Compiling Main             ( x.hs, x.o )

x.hs:1:1: warning: [-Wmissing-signatures]
    Top-level binding with no type signature: x :: Char
Ok, modules loaded: Main (x.o).
Prelude Main> Prelude Describe Main> Ok, modules loaded: Main (x.o).
Prelude Main> Leaving GHCi.

Notice there is no warning about y despite the fact that we changed the file. In your commit, it will report that there's no top-level binding for y (because you're caching the old results).

You can also miss error messages due to this:

bash-3.2$ cat > input-no-errors.txt
:set -Wall -fobject-code
:!echo "x = 'a'" > x.hs
:l x.hs
:!echo "y = 'a' * k" > x.hs
:l x.hs
:q
bash-3.2$ cat input-no-errors.txt | ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/  :? for help
Prelude> Prelude> Prelude> [1 of 1] Compiling Main             ( x.hs, x.o )

x.hs:1:1: warning: [-Wmissing-signatures]
    Top-level binding with no type signature: x :: Char
Ok, modules loaded: Main (x.o).
Prelude Main> Prelude Describe Main> Ok, modules loaded: Main (x.o).
Prelude Main> Leaving GHCi.

There should be a type error or an out of scope error about k. There isn't because we changed the file too quickly. This happened to me a lot in Intero until I fixed it. We can put a delay before writing the file and then it works properly:

bash-3.2$ cat > input-delay.txt
:set -Wall -fobject-code
:!echo "x = 'a'" > x.hs
:l x.hs
:!sleep 1
:!echo "x = 'a' * k" > x.hs
:l x.hs
:q
bash-3.2$ cat input-delay.txt | ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/  :? for help
Prelude> Prelude> Prelude> [1 of 1] Compiling Main             ( x.hs, x.o )

x.hs:1:1: warning: [-Wmissing-signatures]
    Top-level binding with no type signature: x :: Char
Ok, modules loaded: Main (x.o).
Prelude Main> Prelude Main> Prelude Main> [1 of 1] Compiling Main             ( x.hs, x.o )

x.hs:1:11: error: Variable not in scope: k :: Char
Failed, modules loaded: none.
Prelude> Leaving GHCi.

For whatever reason in the GHC API, it ignores files that have changed in <1 second since the last modification.

Editing with flycheck turned on will trigger this a lot. If you just type check on a key binding or file save, you won't notice it that often.

[jyp]

Thanks for the detailed information. I confirm that I am not observing this problem with my version of GHCi (8.0.2) on linux (nixos).

[chrisdone]

It might be an OS X behavior then.

[jyp]

Definitely a bug in GHC(i); should be reported upstream.

…

On Mon, Dec 4, 2017 at 1:46 PM, Chris Done ***@***.***> wrote: It might be an OS X behavior then. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#52 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABsY8PqXdaa1cstXzvW6Cx6aEFxCKUpks5s8-mcgaJpZM4Qaqqd> .