ghc api: `load LoadAllTargets` is not idempotent

While trying to adapt hint for ghc 8.4.1, I've encountered the following phenomenon where an extra load LoadAllTargets line causes errors.

-- warning: the code below creates files A.hs and B.hs in the current working directory
import System.Directory
import Control.Monad.IO.Class
import GHCi.RemoteTypes

import GHC.Paths -- cf. the ghc-paths package
import Unsafe.Coerce

main = do
    writeFile "A.hs" "module Ahidden(a) where { a :: Int; a = 42 }"
    let mod_nameA = mkModuleName "Ahidden"
        mod_targetA = Target (TargetFile "A.hs" Nothing) False Nothing

    runGhc (Just libdir) $ do
        -- setup
        df0 <- getSessionDynFlags
        (df1, _, _) <- parseDynamicFlags df0 []
        setSessionDynFlags df1{
            ghcMode = CompManager,
            hscTarget = HscInterpreted,
            ghcLink = LinkInMemory,
            verbosity = 0
        }

        -- context : *X
        setTargets [mod_targetA]
        load LoadAllTargets
        load LoadAllTargets -- this line causes the next line to fail
        setContext [IIModule mod_nameA]
-- error:
--   ...: Could not find module ‘Ahidden’
--   Use -v to see a list of the files searched for.
        runIOExpr "print a :: IO ()"

runIOExpr e = do
    HValue h <- compileExpr e
    liftIO (unsafeCoerce h :: IO ())

This code works with ghc 8.2. The new behavior probably originates in 1893ba12, which adds flushing of the finder cache (main/Finder.hs) for every dependency analysis; my guess is that this is where the connection between the module name Ahidden and the file A.hs used be tracked.

http://lpaste.net/364298 is a less artificial example of the same behavior.

Trac metadata

Trac field	Value
Version	8.4.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	GHC API
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added GHC API Tbug Trac import labels

Ping? I'd like to know whether this is considered to be a bug. (The question arises because the GHC API has no stability guarantees, and apperently the current behavior is enough for ghci to work. On the other hand, specifying and loading targets by filename incrementally can be quite useful, and it used to work.)

changed milestone to %8.6.1

changed weight to 7

This sounds like a bug to me. I too would expect load to be idempotent.

CCing Jaffacake.

Trac metadata

Trac field	Value
Priority	normal → high
CC	- → Jaffacake

I tried to tackle this and couldn't reproduce — I've run the compiled binary and it prints 42. Also, I've had to add import GHC to compile.

With a freshly built compiler (commit 9976bed24dda9449ac2e3e95fb4bf8b379114a28), here are the steps I took.

Installed ghc-paths:

[nix-shell:~/Projects/ghc2]$ cabal install --with-compiler=`pwd`/inplace/bin/ghc-stage2 --package-db=`pwd`/inplace/lib/package.conf.d ghc-paths --allow-newer
Resolving dependencies...
Configuring ghc-paths-0.1.0.9...
Building ghc-paths-0.1.0.9...
Installed ghc-paths-0.1.0.9

Tried to build:

[nix-shell:~/Projects/ghc2]$ inplace/bin/ghc-stage2 T14994.hs
[1 of 1] Compiling Main             ( T14994.hs, T14994.o )

T14994.hs:19:13: error: Not in scope: ‘ghcMode’
   |
19 |             ghcMode = CompManager,
   |             ^^^^^^^

T14994.hs:20:13: error: Not in scope: ‘hscTarget’
   |
20 |             hscTarget = HscInterpreted,
   |             ^^^^^^^^^

T14994.hs:21:13: error: Not in scope: ‘ghcLink’
   |
21 |             ghcLink = LinkInMemory,
   |             ^^^^^^^

T14994.hs:22:13: error: Not in scope: ‘verbosity’
   |
22 |             verbosity = 0
   |             ^^^^^^^^^

Added import GHC, tried to build:

[nix-shell:~/Projects/ghc2]$ inplace/bin/ghc-stage2 T14994.hs
[1 of 1] Compiling Main             ( T14994.hs, T14994.o )

T14994.hs:6:1: error:
    Could not find module ‘GHC’
    It is a member of the hidden package ‘ghc-8.5’.
    You can run ‘:set -package ghc’ to expose it.
    (Note: this unloads all the modules in the current scope.)
    Use -v to see a list of the files searched for.

Modified the build command by adding -package ghc:

[nix-shell:~/Projects/ghc2]$ inplace/bin/ghc-stage2 T14994.hs -package ghc
[1 of 1] Compiling Main             ( T14994.hs, T14994.o )
Linking T14994 ...

Running:

[nix-shell:~/Projects/ghc2]$ ./T14994 
42

changed milestone to %8.8.1

This won't be fixed in 8.6. Bumping to 8.8.

closed

I'm sorry, but I cannot reproduce this as described either. This is embarrassing, because I really spent a lot of time on tracking this down. But I did patch the compiler at the time, so it's possible that I ended up breaking it and never testing my findings with a pristine version.

I'll have to retrace my steps. I'll hopefully find time for that after the next weekend. In the meantime I'm marking this as invalid.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedInvalid

added Phigh label