And then an eval comment in (e.g.) Foo causes the module to be added and explicitly interpreted by path:
ghci> :add *src/Foo.hs
Then, we have Foo loaded by name (Foo) and by path (src/Foo.hs), which triggers the dreaded bug.
At the time I proposed this fix, correctly:
I think we can fix this by keeping track of how each module is added to the session — as a path or as a module name — and then only using that form going forward.
I threaded some extra information to the :show targets parser to track if modules were listed as names or paths, but then at the end of Ghci::interpret_module I would always insert the module into the target set as a TargetKind::Path, meaning that the next time the comment was evaluated, the module would be loaded as a path, causing the
error.
In https://github.com/MercuryTechnologies/ghciwatch/pull/214, we had a situation where modules were loaded:
And then an eval comment in (e.g.)
Foo
causes the module to be added and explicitly interpreted by path:Then, we have
Foo
loaded by name (Foo
) and by path (src/Foo.hs
), which triggers the dreaded bug.At the time I proposed this fix, correctly:
I threaded some extra information to the
:show targets
parser to track if modules were listed as names or paths, but then at the end ofGhci::interpret_module
I would always insert the module into the target set as aTargetKind::Path
, meaning that the next time the comment was evaluated, the module would be loaded as a path, causing the error.https://github.com/MercuryTechnologies/ghciwatch/blob/dbba61bbdec9a86f97051b12647e51b7be4fd484/src/ghci/mod.rs#L698-L699
This fixes the bug and adds an
assert!
to fail faster and more obviously if it happens again.Prior art
37
77
125
214