Closed aavogt closed 1 month ago
Hmm, I actually think that ghciwatch
and ghcid
run tests in the same way (they both enter the test command you give directly into the GHCi session). Maybe there's something different in the way ghcid
constructs the GHCi session that makes it resolve differently? Either way, I do think you should fully-qualify your test functions.
Oh actually, this is probably because if you tell ghciwatch
to run a GHCi session that loads M.hs
and then you modify T.hs
, ghciwatch
will actually :add T.hs
to the GHCi session. ghcid
will just issue a naïve :reload
command (so T.hs
will only be loaded if some other already-loaded module imports it), which probably changes the bindings ghciwatch
knows about.
Anyways, I'm going to close this: if you want to run M.f
, use --test-ghci M.f
.
What happened?
On the first load, and when I save src/M.hs, this runs M.f
ghciwatch --command 'ghci -isrc M' --test-ghci f
But if I changeT.hs
(imported by M), ghciwatch tries to run a different testT.f
whether or not it exists.What did you expect to happen?
For
ghcid -c 'ghci -isrc M' -Tf
, thef
is alwaysM.f
. I did not expect a 'variable not in scope' error. If both T.f and M.f exist, ghciwatch could evaluate both, or just the more recently changed one.For now my workaround is to fully qualify the test expressions.
Steps to reproduce the issue
No response
The version of ghciwatch with the bug
ghciwatch 0.5.11