Skip to content

Incorrect ASSERT for buildPatSyn

Consider the following two files:

-- A.hs
{-# LANGUAGE PatternSynonyms #-}
module A where
pattern Single :: a -> a
pattern Single x = x

-- B.hs
module B where
import A
Single y = True

When I build these using one-shot compilation using a debugged GHC (i.e. with ASSERTs) I get the following error:

[ezyang@hs01 ghc-quick3]$ inplace/bin/ghc-stage2 -c A.hs -fforce-recomp 
[ezyang@hs01 ghc-quick3]$ inplace/bin/ghc-stage2 -c B.hs -fforce-recomp 
ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 7.11.20150918 for x86_64-unknown-linux):
        ASSERT failed! file compiler/iface/BuildTyCl.hs, line 210

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

I expanded the assert and discovered it was claiming the universal type variables of the matcher should be equal to the type variables of the pattern declaration. This assert cannot possibly be right: the matcher and the pattern declaration are typechecked separately and there's no reason that the local binders should actually be the same. The equality test here should be done up to alpha-renaming.

The other thing I found a bit puzzling was whether or not it mattered whether or not we used the local type variables from the matcher or the freshly bound ones. I suppose if we are consistent it shouldn't matter, so I don't think the code is buggy, just a bad ASSERT.

BTW: this assert problem doesn't show up with --make because the assert occurs during typechecking of interface files, and with --make we don't need to typecheck an interface file.

Trac metadata
Trac field Value
Version 7.11
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler (Type checker)
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