Crash in TcEnv.lhs line 461

[mikhail.vorozhtsov]

The attached program makes GHC panic:

$ ghc-7.3.20110828 -fforce-recomp Bug.hs
[1 of 1] Compiling Main             ( Bug.hs, Bug.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.3.20110828 for x86_64-unknown-linux):
	ASSERT failed! file compiler/typecheck/TcEnv.lhs line 461
register{v amY} [lid]
forall n{tv amZ} [tv].
main:Main.HDropClass{tc r18} n{tv amZ} [tv] rs{tv amV} [ssk] =>
ghc-prim:GHC.Types.Bool{(w) tc 3c}
-> main:Main.Peano{tc ru} n{tv amZ} [tv]
-> main:Main.WaitOps{tc ro}
     (main:Main.HDrop{tc r17} n{tv amZ} [tv] rs{tv amV} [ssk])
-> ghc-prim:GHC.Types.IO{tc 32I} ghc-prim:GHC.Types.Bool{(w) tc 3c}

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

[daniel.is.fischer]

Doing a validate --slow, the same assert failed in

indexed-types/should_compile T3787
programs/rittri rittri
deSugar/should_run dsrun021, dsrun022, mc01, mc02
simplCore/should_run T3591
simplCore/should_compile strict-float

[simonpj@…]

commit eb46e0de6eab60483f38ed2088d9de13d8e74e2f

Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Thu Sep 1 08:28:36 2011 +0100

    Fix the trimming of bind_fvs (fixes Trac #5439)
    
    For the bind_fvs field of FunBind/PatBind, we need to be careful to
    keep track of uses of all functions in this module (although not
    imported ones).  Moreover in TcBinds.decideGeneralisationPlan we
    need to take note of uses of lexically scoped type variables.
    
    These two buglets led to a (useful) assertion failure in TcEnv.

 compiler/hsSyn/HsBinds.lhs       |   52 ++++++++++++++++++++++++----
 compiler/rename/RnBinds.lhs      |   70 +++++++++++++++++---------------------
 compiler/typecheck/TcBinds.lhs   |   12 +++++-
 compiler/typecheck/TcRnTypes.lhs |   36 +++++++++++++++++++-
 4 files changed, 121 insertions(+), 49 deletions(-)

[simonpj]

Fixed!

[mikhail.vorozhtsov]

I'm still getting the panic on my file.

$ git log -n 3 --format=oneline
fa71e6c795489ec267e0d048395c2c52bea6a164 Fix #4988: we were wrongly running exception h...
c27df60d69ad54a69723510c57e238f31a59c532 Two small further extensions to associated typ...
eb46e0de6eab60483f38ed2088d9de13d8e74e2f Fix the trimming of bind_fvs (fixes Trac #5439...
$ ./validate --slow
...
$ grep panic testlog
$ ./inplace/bin/ghc-stage1 -c -fforce-recomp ~/Bug.hs

/home/mikhail_vorozhtsov/Bug.hs:83:39:
    Couldn't match expected type `Peano n0'
                with actual type `Attempt α0'
    In the return type of a call of `Failure'
    In the second argument of `($)', namely
      `Failure (e :: SomeException)'
    In the second argument of `($)', namely
      `inj $ Failure (e :: SomeException)'

So far so good (the type error is expected), but then:

./inplace/bin/ghc-stage2 -c -fforce-recomp ~/Bug.hs
ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 7.3.20110901 for x86_64-unknown-linux):
	ASSERT failed! file compiler/typecheck/TcEnv.lhs line 461
register{v amR} [lid]
forall n{tv amS} [tv].
main:Main.HDropClass{tc r1d} n{tv amS} [tv] rs{tv amO} [ssk] =>
ghc-prim:GHC.Types.Bool{(w) tc 3c}
-> main:Main.Peano{tc rx} n{tv amS} [tv]
-> main:Main.WaitOps{tc rr}
     (main:Main.HDrop{tc r1c} n{tv amS} [tv] rs{tv amO} [ssk])
-> ghc-prim:GHC.Types.IO{tc 32I} ghc-prim:GHC.Types.Bool{(w) tc 3c}

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

If I fix the type error reported by the stage1 compiler (by replacing "$ inj $" with "$ inj n $"), the panic goes away. The bootstrap compiler is GHC 7.0.3.

[simonpj@…]

commit b5b4aae437bba8c93bbe29e3678debceeb3f076e

Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Thu Sep 1 15:54:39 2011 +0100

    Wibble to fix of Trac #5439: deal with the error-recovery case
    
    Even if we are recovering from a typecheck error, we should still do
    the right thing for the "closed" flag.  Otherwise we get an assert
    failure, and potentially different behaviour when the user fixes
    the original type error.

 compiler/typecheck/TcBinds.lhs |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

[simonpj]

Ah yes. How true. I was sloppy about the case when we are recovering from a type error. Try now.

Simon