#8639 closed bug (fixed)

GHC API `runStmt` overrides qualified import of `it` variable

Reported by: agibiansky Owned by:
Priority: normal Milestone:
Component: GHC API Version: 7.6.3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: ghc-api/T8639_api, ghci/scripts/T8639
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

The runStmt function in InteractiveEval creates an it variable storing the last result. However, this variable somehow shadows qualified variables with the name it. For instance, importing Test.Hspec, running any statement, and then trying to use Test.Hspec.it (qualified) results in an "out of scope" error.

The following small program demonstrates this:

import GHC
import GhcMonad
import Outputable
import GHC.Paths

main = runGhc (Just libdir) $ do
  flags <- getSessionDynFlags
  setSessionDynFlags (flags{ hscTarget = HscInterpreted, ghcLink = LinkInMemory})
  imps <- mapM parseImportDecl ["import Prelude", "import Test.Hspec"]
  setContext (map IIDecl imps)

  -- With the next line, you get an "Not in scope" exception.
  -- If you comment out this runStmt, it runs without error and prints the type.
  runStmt "3" RunToCompletion

  exprType "Test.Hspec.it" >>= (liftIO . putStrLn . showPpr flags)

GHCi somehow avoids this, but I have no idea how and could not figure it out from the sources.

What's going on?

Change History (7)

comment:1 Changed 18 months ago by simonpj

Good point. I'll fix this.

I think you missed out some code in the test:

           setSessionDynFlags (flags{ hscTarget = HscInterpreted, ghcLink = LinkInMemory})
*          target <- guessTarget "Test/Hspec.hs" Nothing
*          setTargets [target]
*          load LoadAllTargets
           imps <- mapM parseImportDecl ["import Prelude", "import Test.Hspec"]

The lines marked * are important!

When I run this program (with my patched compiler), I see

bash$ ghc -o T8639 T8639.hs
bash$ ./T8639
3
GHC.Types.Bool

But if I redirect the output I lose the "3":

bash$ ghc -o T8639 T8639.hs
bash$ ./T8639 > foo
bash$ cat foo
GHC.Types.Bool

I have no idea why but it's a different problem. Does anyone have ideas?

Simon

Last edited 18 months ago by simonpj (previous) (diff)

comment:2 Changed 18 months ago by agibiansky

Simon,

I'm not sure if this is relevant to the bug, but just FYI, the program I posted was complete. I did not have Hspec.hs as a target, I simply had the hspec package installed via cabal install (as a user normally would.) I just verified to make sure - if you copy and paste the entire program and compile with ghc 7.6.3, everything works (or doesn't work) as reported.

Thanks for tackling this!

-- Andrew

comment:3 Changed 18 months ago by simonpj

Turns out that you need also

  runStmt "hFlush stdout" RunToCompletion

to make the output appear when redirecting. Weird.

Simon

comment:4 Changed 18 months ago by Simon Peyton Jones <simonpj@…>

In 5dffb4ac14b53362ebe9a67c5c6a01f9c9c25229/ghc:

Refactor the way shadowing in handled in GHCi

If you say
  ghci> import Foo( T )
  ghci> data T = MkT
  ghci> data T = XXX
then the second 'data T' should shadow the first.  But the qualified
Foo.T should still be available.  We really weren't handling this
correctly at all, resulting in Trac #8639 and #8628 among others

This patch:

* Add RdrName.extendGlobalRdrEnv, which does shadowing properly

* Change HscTypes.icExtendGblRdrEnv (was badly-named icPlusGblRdrEnv)
  to use the new function

* Change RnNames.extendGobalRdrEnvRn to use the new function

* Move gresFrom Avails into RdrName
* Better pprGlobalRdrEnv function in RdrName

comment:5 Changed 18 months ago by Simon Peyton Jones <simonpj@…>

In 0a0ca8097d52838bf6faa883dfab4f84a7e89527/testsuite:

Test Trac #8639 (just the GHCi version)

comment:6 Changed 18 months ago by Simon Peyton Jones <simonpj@…>

comment:7 Changed 18 months ago by simonpj

  • Resolution set to fixed
  • Status changed from new to closed
  • Test Case set to ghc-api/T8639_api, ghci/scripts/T8639

Thanks for identifying this so well.

Simon

Note: See TracTickets for help on using tickets.