#14884 closed bug (fixed)

Type holes cause assertion failure in ghc-stage2 compiler during type checking

Reported by: sighingnow Owned by:
Priority: normal Milestone:
Component: Compiler (Type checker) Version:
Keywords: TypedHoles Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash or panic Test Case: typecheck/should_fail/T14884
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


ghc-stage2 panic! due to assertion failure when compiling the following code with ghc-stage2 Bug.hs

module Bug where

x :: IO ()
x = _ print "abc"


λ inplace\bin\ghc-stage2 Bug.hs
[1 of 1] Compiling Bug              ( Bug.hs, Bug.o )
ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 8.5.20180225 for x86_64-unknown-mingw32):
        ASSERT failed!
  Call stack:
      CallStack (from HasCallStack):
        callStackDoc, called at compiler\utils\Outputable.hs:1150:37 in ghc:Outputable
        pprPanic, called at compiler\utils\Outputable.hs:1206:5 in ghc:Outputable
        assertPprPanic, called at compiler\\typecheck\\TcType.hs:1187:83 in ghc:TcType
CallStack (from -prof):
  TcInteract.solve_loop (compiler\typecheck\TcInteract.hs:(247,9)-(254,44))
  TcInteract.solveSimples (compiler\typecheck\TcInteract.hs:(241,5)-(243,21))
  TcRnDriver.simplifyTop (compiler\typecheck\TcRnDriver.hs:408:25-39)
  TcRnDriver.tcRnSrcDecls (compiler\typecheck\TcRnDriver.hs:254:25-65)

The failed assertion is checkTcLevelInvariant ctxt_tclvl tv_tclvl in isTouchableMetaTyVar:

isTouchableMetaTyVar :: TcLevel -> TcTyVar -> Bool
isTouchableMetaTyVar ctxt_tclvl tv
  | isTyVar tv -- See Note [Coercion variables in free variable lists]
  = ASSERT2( tcIsTcTyVar tv, ppr tv )
    case tcTyVarDetails tv of
      MetaTv { mtv_tclvl = tv_tclvl }
        -> ASSERT2( checkTcLevelInvariant ctxt_tclvl tv_tclvl,
                    ppr tv $$ ppr tv_tclvl $$ ppr ctxt_tclvl )
           tv_tclvl `sameDepthAs` ctxt_tclvl
      _ -> False
  | otherwise = False

Notice that the ghc-stage1 compiler doesn't panic and report the type hole correctly. This seems a regression and I have checked that ghc-8.2.2 also works well.

Change History (6)

comment:1 Changed 19 months ago by simonpj

I've seen this before.

It arises during error reporting, when the (now quite elaborate) TcErrors.validSubstitutions code invokes the constraint solver. To avoid the assertion error we need to set the level correctly, and we aren't doing that yet.

It's unsatisfactory, but I think harmless.

comment:2 Changed 18 months ago by simonpj

Keywords: TypedHoles added

comment:3 Changed 18 months ago by goldfire

My untested hunch is that my recent fix for #14066 fixed this on the way. Will test in a bit.

comment:4 Changed 18 months ago by simonpj

I somewhat doubt it.. the calls to the constraint solver from TcErrors.validSubstitutions are wonky. I discussed this with Mathias, and he is on the case.

comment:5 Changed 18 months ago by Richard Eisenberg <rae@…>

In 07abff71/ghc:

Test #14884, #14969

These were fixed by faec8d358985e5d0bf363bd96f23fe76c9e281f7

test cases: typecheck/should_fail/T14884

comment:6 Changed 18 months ago by goldfire

Resolution: fixed
Status: newclosed
Test Case: typecheck/should_fail/T14884

Yes, they were wonky. I fixed them, as they caused failures in my work on #14066. Sorry to waste Matthias's time!

Note: See TracTickets for help on using tickets.