Opened 4 years ago

Last modified 18 months ago

#11812 new bug

Template Haskell can induce non-unique Uniques

Reported by: goldfire Owned by:
Priority: normal Milestone:
Component: Template Haskell Version: 8.1
Keywords: Cc: erikd
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by RyanGlScott)

When quoting a Template Haskell expression (or type), you can get your hands on renamed variables. These variables have assigned Uniques. If you then use the same variable locally in different top-level expressions, chaos can ensue. It's certainly expected that something bizarre would happen if you used the same Unique twice within the same scope, but it surprised me that using the same Unique twice in different scopes would cause a problem.

Below is the rather hard-won reduced test case:

{-# LANGUAGE TemplateHaskell, PolyKinds, RankNTypes, TypeFamilies #-}

module Bug where

import Language.Haskell.TH
import Data.Type.Equality

type Const a b = a

$(do ForallT [PlainTV n] _ _ <- [t| forall n. n |]
     let noBang = Bang NoSourceUnpackedness NoSourceStrictness
     return [ClosedTypeFamilyD
             (TypeFamilyHead (mkName "F1")
              [ KindedTV (mkName "a") (VarT n)
              , PlainTV (mkName "b") ]
              (KindSig (VarT n))
             [TySynEqn [VarT (mkName "a"), VarT (mkName "b")]
                       (ConT ''Const `AppT` VarT (mkName "a")
                                     `AppT` (ConT (mkName "T1") `AppT` VarT (mkName "a")
                                                                `AppT` VarT (mkName "b")))]
             (mkName "T1")
             [ KindedTV (mkName "a") (VarT n)
             , PlainTV (mkName "b")
             , PlainTV (mkName "c")]
             [NormalC (mkName "K1")
              [(noBang, ConT ''(:~:) `AppT` VarT (mkName "c")
                                    `AppT` (ConT (mkName "F1") `AppT` VarT (mkName "a")
                                                                `AppT` VarT (mkName "b")))]]

This blob produces

type family F1 (a :: n_auRf) b :: n_auRf where
  F1 a b = Const a (T1 a b)
data T1 (a :: n_auRf) b c = K1 ((:~:) c (F1 a b))

which compiles fine when typed in directly. Note that this hinges on the SigTv behavior of kind variables in non-CUSK declarations, but I don't think that's the nub of the problem.

What happens is this: during renaming, the ns are renamed to have the same Unique, because n is Exact. Type-checking invents SigTvs for each n. Naturally, both ns have different IORefs stored in their TcTyVarDetails. When the two ns are compared during checking, though, their Uniques are the same, and so nothing happens -- even though they should be unified. The upshot is that we get one logical variable n with different IORefs in different occurrences, causing chaos.

It might be reasonable to punt on this, but we should document in the manual what the problem is. It puzzled me for quite a while when the problem came up in real code!

Change History (5)

comment:1 Changed 3 years ago by erikd

Cc: erikd added

comment:2 Changed 2 years ago by RyanGlScott

Description: modified (diff)

comment:3 Changed 2 years ago by RyanGlScott

To make things worse, this program now panics on GHC 8.2.1:

$ /opt/ghc/8.2.1/bin/ghc Bug.hs
[1 of 1] Compiling Bug              ( Bug.hs, Bug.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 8.2.1 for x86_64-unknown-linux):
        expectJust zonkTcTyVarToVar
CallStack (from HasCallStack):
  error, called at compiler/utils/Maybes.hs:53:27 in ghc:Maybes
  expectJust, called at compiler/typecheck/TcType.hs:1583:21 in ghc:TcType

comment:4 Changed 2 years ago by RyanGlScott

Hrm. The panic seems to have been introduced in either commit 77bb09270c70455bbd547470c4e995707d19f37d (Re-add FunTy (big patch)) or e368f3265b80aeb337fbac3f6a70ee54ab14edfd (Major patch to introduce TyConBinder).

(It's hard to say since commit 77bb09270c70455bbd547470c4e995707d19f37d doesn't build, but the commit before that definitely did not exhibit the panic, and commit e368f3265b80aeb337fbac3f6a70ee54ab14edfd does.)

comment:5 Changed 18 months ago by mgsloan

Looks like having multiple bindings of the same unique name can also cause erroneous unused binding warnings:

Note: See TracTickets for help on using tickets.