Skip to content
Snippets Groups Projects

TyVar ASSERT failure in type family checking: T12041

    • Closed Issue created by Simon Peyton Jones @simonpj

    In HEAD, if you build the compiler with -DDEBUG, test indexed-types/should_fail/T12041 fails thus

    +ghc: panic! (the 'impossible' happened)
+  (GHC version 8.1.20161109 for x86_64-unknown-linux):
+	ASSERT failed!
+  i_axb
+  Call stack:
+      CallStack (from HasCallStack):
+        prettyCurrentCallStack, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable
+        callStackDoc, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable
+        assertPprPanic, called at compiler/typecheck/TcType.hs:<line>:<column> in <package-id>:TcType
+  Call stack:
+      CallStack (from HasCallStack):
+        prettyCurrentCallStack, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable
+        callStackDoc, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable
+        pprPanic, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable
+        assertPprPanic, called at compiler/typecheck/TcType.hs:<line>:<column> in <package-id>:TcType

    A TyVar is showing up where a TcTyVar is expected.

    I'm pretty certain this is harmless in a production compiler, but reflects an infelicity somewhere.

    Trac metadata
    Trac field Value
    Version 8.0.1
    Type Bug
    TypeOfFailure OtherFailure
    Priority normal
    Resolution Unresolved
    Component Compiler
    Test case
    Differential revisions
    BlockedBy
    Related
    Blocking
    CC
    Operating system
    Architecture
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    Please register or sign in to reply