Open umnikos opened 4 years ago
The bug is that in GHC 8.4 and above, starting with a working bug.hs
:
1) ghci bug.hs
2) Modify bug.hs to remove the closing paren
3) :reload
4) putStrLn "hello"
In GHC 8.2 and below that prints out hello
. In GHC 8.4 and above it doesn't. The way ghcid looks for the end of the stream is by calling putStrLn and waiting for the results to appear, so once putStrLn gets broken, it never knows that ghci has finished.
I think I have a workaround, just testing out now...
Workarounds I thought of:
:module
. That makes it work, and keeps the loaded set, but means that anything sent to ghcid to evaluate (e.g. --test
) stops working.:show editor
to detect when a command has finished. Unfortunately only goes to stderr, so I don't know that both stdout and stderr have finished.The reason it works if you have the code broken before you start is that then ghci doesn't load your module into the current prompt. I think in GHC 8.2 if it fails to load the Main module it keeps the old one around, rather than replacing the context with something that is known to be bust. I raised an upstream bug https://gitlab.haskell.org/ghc/ghc/issues/17549
Closing the issue since it is ghci-related (despite the title) and thus not a ghcid bug.
Ghcid is primarily about avoiding Ghci bugs so I may well have to figure out a way round it in the short term. Keeping it open for now.
Steps to reproduce the bug:
import Data.List (permutations)
ghcid --command="ghci bug.hs"
import Data.List (permutations
This bug doesn't occur if the file stats out wrong, only if it reloads into a wrong file.
If you attempt the same steps in ghci the bug does not occur, thus this is should be a ghcid-specific bug.