Skip to content

GHCi panics using -fdefer-type-errors when pattern matching on types with multiple constructors using out-of-scope variables

Summary

With -fdefer-type-errors enabled GHCi will panic on certain errors involving pattern matching on types with multiple constructors. At least as far as I can tell.

Steps to reproduce

The following is the smallest module I could find that causes the panic:

foo = x
  where (x:xs) = bar

GHCi command and output:

▶ ghci -ignore-dot-ghci -fdefer-type-errors Foo.hs
GHCi, version 8.6.5: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling Main             ( Foo.hs, interpreted )

Foo.hs:2:18: warning: [-Wdeferred-out-of-scope-variables]
    Variable not in scope: bar :: [a1]
  |
2 |   where (x:xs) = bar
  |                  ^^^
ghc: panic! (the 'impossible' happened)
  (GHC version 8.6.5 for x86_64-unknown-linux):
        getIdFromTrivialExpr
  \ (@ a_a1x4) -> case ds_s1yU @ a_a1x4 of wild_Xb { }
  Call stack:
      CallStack (from HasCallStack):
        callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
        pprPanic, called at compiler/coreSyn/CoreUtils.hs:977:18 in ghc:CoreUtils

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

> 

The equivalent using let also panics. The pattern match in the where is neccessary, as is using a matched variable in the main expression (either one will do). Matching on a tuple does not cause a panic, nor does matching on data Foo a = Foo a a, but matching on data Foo a = Foo a a | Bar a a panics regardless of which constructor is chosen.

Expected behavior

GHCi doesn't panic, but either loads the module correctly or explains why it can't do so.

Environment

  • GHC version used: 8.6.5

Optional:

  • Operating System: Arch-linux
  • System Architecture: x86_64
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information