Evaluating commands fails after #168

[9999years]

#168 introduced another bug with eval commands. The actual bugfix here is relatively small, but I needed some architectural changes in the test harness (to support restarting the ghciwatch session) and in the ghciwatch codebase to make these changes.

• Removes the system of Modes introduced in Run tests on save #11 and gutted in Make --errors output compatible with ghcid #78. This grouped ghci output into buffers based on the "mode" ghciwatch was in when the output was produced (modules being compiled, tests being run, internal data being gathered, etc.). Over time this was used less and less. Now we parse diagnostics out of all compiler output and it's fine.
• Also removes the Ghci::process_ghc_messages method introduced in Fix "module defined in multiple files" by parsing GHC diagnostics #77. The idea was that methods like Stdout::prompt would return a list of parsed GHC messages/diagnostics, and those would be processed by Ghci. In practice, it was difficult to remember to pass the lists of messages to process_ghc_messages consistently. Now, each method that produces diagnostics takes a &mut CompilationLog. There's many places where messages are produced, but only a few where messages need to be written out (after reloads, after startup), so this is a lot more convenient.

Bug reproduction details

There's two bugs here: module '...' is not interpreted and module '...' defined in multiple files. My attempted fix for the first bug in #168 caused the second bug. This PR fixes both.

First, you load a ghci session:

$ ghci
[1 of 4] Compiling MyLib            ( src/MyLib.hs, interpreted )
[2 of 4] Compiling MyModule         ( src/MyModule.hs, interpreted )
[3 of 4] Compiling Paths_my_simple_package ( /Users/wiggles/ghciwatch/tests/data/simple/dist-newstyle/build/aarch64-osx/ghc-9.6.3/my-simple-package-0.1.0.0/l/test-dev/build/test-dev/autogen/Paths_my_simple_package.hs, interpreted )
[4 of 4] Compiling TestMain         ( test/TestMain.hs, interpreted )
Ok, four modules loaded.
ghci> :quit

This interprets each module. When the GHC option -fwrite-if-simplified-core (introduced in GHC 9.4) is used, loading the ghci session additionally writes interface files for each module:

The interface file will contain all the bindings for a module. From this interface file we can restart code generation to produce byte-code.

Then, you can load a new ghci session, which will load the interface modules and use them to generate ghci byte-code directly. Critically, this means that the modules are not considered to be "interpreted", leading to this error message:

$ ghci
Ok, four modules loaded.
ghci> :module + *MyLib
module 'MyLib' is not interpreted; try ':add *MyLib' first

How ghciwatch triggers the bug

When ghciwatch's --enable-eval flag is used, an eval command runMyCommand for a module MyModule is executed roughly like this:

> :module + *MyModule
> runMyCommand
> :module - *MyModule

:module + *MyModule brings the top-level definitions of MyModule into scope, so that eval commands can refer to definitions in the module they're defined in.

@parsonsmatt noticed that if ghci loaded a module from one of these interface files, evaluating commands in that file would fail:

GHCi, version 9.6.2: https://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from .ghci
• ghci started in 5.52s

• Adding modules to ghci:
  • test/Foo.hs

Ok, 3140 modules loaded.
• test/Foo.hs:25:7: runMyTests
module 'Foo' is not interpreted; try ':add *Foo' first

I initially attempted to fix this in #168, which added an explicit :add *Foo before running the eval command, which forces the module to be interpreted.

Unfortunately, using the module name instead of the module path could lead to the module being added twice, causing the dreaded module defined in multiple files bug (see #37, #77, #125).

[linear]

DUX-1650 Eval fails after #168

[9999years]

Here's the actual bugfix, making sure the modules are interpreted and using the module path (instead of the module name) to import them.

[github-actions]

A PR to release these changes has been created, bumping the version from 0.5.3 to 0.5.4.