#15007 closed bug (fixed)

Don't keep shadowed variables in ghci, both renamer and type checker

Reported by: sighingnow Owned by:
Priority: normal Milestone: 8.6.1
Component: GHCi Version: 8.5
Keywords: TypedHoles Cc: Tritlo
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Incorrect error/warning at compile-time Test Case:
Blocked By: Blocking:
Related Tickets: #11547 #14052 #15202 Differential Rev(s): Phab:D4909
Wiki Page:

Description (last modified by RyanGlScott)

In ticket:14052, we reverted Phab:D2447, then ticket:11547 exists in HEAD again. In ticket:14052#comment:25 and ticket:14052#comment:10, we decide that shadowed variables shouldn't be keep at all. This ticket is created to track the idea.

The same error of ticket:11547 was also reported in ticket:14996#comment:2,

$ inplace/bin/ghc-stage2 --interactive
GHCi, version 8.5.20180403: http://www.haskell.org/ghc/  :? for help
Prelude> 1
1
Prelude> 1
1
Prelude> _

<interactive>:1:1: error:
    GHC internal error: ‘Ghci1.it’ is not in scope during type > checking, but it passed the renamer
   tcl_env of environment: []

(giving "1" twice is needed to reproduce the error)

NB: input "1" twice to create shadowed context is necessary to reproduce this bug.

Change History (23)

comment:1 Changed 18 months ago by sighingnow

Owner: set to sighingnow

comment:2 Changed 17 months ago by RyanGlScott

Description: modified (diff)
Keywords: TypedHoles added

comment:3 Changed 17 months ago by RyanGlScott

Similar shenanigans:

$ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive
GHCi, version 8.5.20180420: http://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> data F
λ> data F
λ> _

<interactive>:1:1: error:
    GHC internal error: ‘Ghci1.$trModule’ is not in scope during type checking, but it passed the renamer
    tcl_env of environment: []

comment:4 Changed 16 months ago by RyanGlScott

Another example from #15202:

Run ghc --interactive, and at the prompt type

default ()
fish :: Eq a => a; fish = undefined
foo :: String; foo = show _

The following error appears:

<interactive>:1:1: error:
    GHC internal error: ‘Ghci1.$trModule’ is not in scope during type checking, but it passed the renamer
    tcl_env of environment: [r2CZ :-> Identifier[foo::String, TopLevelLet]]

comment:5 Changed 15 months ago by bgamari

Milestone: 8.6.18.8.1

These won't be addressed in GHC 8.6.

comment:6 Changed 15 months ago by Tritlo

Cc: Tritlo added

comment:7 Changed 15 months ago by sighingnow

Owner: sighingnow deleted

comment:9 Changed 15 months ago by bgamari

Milestone: 8.8.18.6.1

comment:10 Changed 15 months ago by osa1

Differential Rev(s): Phab:D4909
Status: newpatch

comment:11 Changed 15 months ago by osa1

Status: patchnew

Reverting this back to "new". It seems to me that the patch doesn't actually fix this problem, but works around it. Please make the status "patch" again if I'm wrong.

comment:12 Changed 15 months ago by Ömer Sinan Ağacan <omeragacan@…>

In 39de4e3d/ghc:

Fix errors caused by invalid candidates leaking from hole fits

This is a one line fix (and a note) that fixes four tickets, #15007,
 #15321 and #15202, #15314

The issue was that errors caused by illegal candidates (according to GHC
stage or being internal names) were leaking to the user, causing
bewildering error messages. If a candidate causes the type checker to
error, it is not a valid hole fit, and should be discarded.

As mentioned in #15321, this can cause a pattern of omissions, which
might be hard to discover. A better approach would be to gather the
error messages, and ask users to report them as GHC bugs. This will be
implemented in a subsequent change.

Reviewers: bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #15007, #15321, #15202, #15314

Differential Revision: https://phabricator.haskell.org/D4909

comment:13 Changed 15 months ago by simonpj

I don't see a regression test -- please add one?

comment:14 Changed 15 months ago by sighingnow

This ticket isn't fixed by Phab:D4909. With a debug-enabled stage2 compiler, for the script in description, we will get a panic:

Prelude> 1
1
(0.02 secs, 65,728 bytes)
Prelude> 1
1
(0.00 secs, 64,352 bytes)
Prelude> _
ghc-stage2.exe: panic! (the 'impossible' happened)
  (GHC version 8.7.20180629 for x86_64-unknown-mingw32):
        ASSERT failed!
  Cur lvl = 1
  Imp lvl = 1
  Call stack:
      CallStack (from HasCallStack):
        callStackDoc, called at compiler\utils\Outputable.hs:1164:37 in ghc:Outputable
        pprPanic, called at compiler\utils\Outputable.hs:1223:5 in ghc:Outputable
        assertPprPanic, called at compiler\\typecheck\\TcSimplify.hs:1548:120 in ghc:TcSimplify
CallStack (from -prof):
  HscMain.ioMsgMaybe (compiler\main\HscMain.hs:(252,1)-(257,128))
  HscMain.hscParsedStmt (compiler\main\HscMain.hs:(1548,1)-(1564,36))
  HscMain.hscStmtWithLocation (compiler\main\HscMain.hs:(1533,1)-(1541,50))
  GHC.withCleanupSession (compiler\main\GHC.hs:(469,1)-(477,27))
  GHC.runGhc (compiler\main\GHC.hs:(444,1)-(449,26))
  GHC.defaultErrorHandler (compiler\main\GHC.hs:(384,1)-(416,7))

Besides, this ticket is intend to solve the problem described in #11547, the GHC internal error (for script reported by #11547) still occurs after Phab:D4909.

comment:15 Changed 15 months ago by sighingnow

The program in #15314 now triggers the same assertion failure as comment:14 after Phab:D4909.

Prelude> let x = ()
Prelude> let x = ()
Prelude> :t _

comment:16 Changed 15 months ago by Ömer Sinan Ağacan <omeragacan@…>

In f6ac0833/ghc:

Add regression test for #15007

comment:17 Changed 15 months ago by osa1

sighingnow, are you sure you rebuilt it correctly? I'm also using a debug-enabled compiler and here are the outputs I'm getting:

~ $ ghc-stage2 --interactive
GHCi, version 8.7.20180704: http://www.haskell.org/ghc/  :? for help
Prelude> 1
1
Prelude> 1
1
Prelude> _

<interactive>:3:1: error:
    • Found hole: _ :: t
      Where: ‘t’ is a rigid type variable bound by
               the inferred type of it :: t
               at <interactive>:3:1
    • In the expression: _
      In an equation for ‘it’: it = _
    • Relevant bindings include it :: t (bound at <interactive>:3:1)
Prelude>
~ $ ghc-stage2 --interactive
GHCi, version 8.7.20180704: http://www.haskell.org/ghc/  :? for help
Prelude> let x = ()
Prelude> let x = ()
Prelude> :t _

<interactive>:1:1: error:
    • Found hole: _ :: t
      Where: ‘t’ is a rigid type variable bound by
               the inferred type of it :: t
               at <interactive>:1:1
    • In the expression: _
Prelude>

comment:18 Changed 15 months ago by sighingnow

I have rebuilt the stage2 compiler after manually delete all .o and .hi files in compiler/stage2/build and still get the same panic. I will try a fresh build later.

comment:19 Changed 15 months ago by osa1

I just validated with the regression tests so it should be fine after a make clean.

comment:20 Changed 15 months ago by sighingnow

osa1: I still get the same assertion failure with comment:14 after a fresh debug-enabled build. My build flavors is:

SRC_HC_OPTS        = -O -H64m
GhcStage1HcOpts    = -O
GhcStage2HcOpts    = -O -DDEBUG
GhcLibHcOpts       = -O -dcore-lint
BUILD_PROF_LIBS    = YES
SplitObjs          = NO
SplitSections      = NO
HADDOCK_DOCS       = NO
BUILD_SPHINX_HTML  = NO
BUILD_SPHINX_PDF   = NO
BUILD_MAN          = NO

LAX_DEPENDENCIES   = YES
GhcProfiled        = YES
INTEGER_LIBRARY      = integer-simple

If I remove the -DDEBUG in GhcStage2HcOpts and rebuild ghc-stage2, I can get the same error message with comment:17.

comment:21 Changed 15 months ago by osa1

I was using GhcDebugged = YES but apparently that doesn't add -DDEBUG, it just adds -debug.

It seems this ticket needs more work.

comment:23 Changed 14 months ago by osa1

Resolution: fixed
Status: newclosed

We have a ticket for the panic this caused: #15384. Closing this one as fixed.

Note: See TracTickets for help on using tickets.