runtimeRep1TyVar's Unique might clash
GHC defines runtimeRep1TyVar
that is useful when writing wired-in levity-polymorphic functions. It gets its Unique from mkTemplateTyVars
, which produces a fixed sequence of Uniques. In order to name runtimeRep1TyVar
q
(in error messages, etc.), the first 16 vars are dropped. The problem is that runtimeRep1TyVar
is sometimes used in places where another call to mkTemplateTyVars
is called. As it turns out, these other uses always have a fixed number of variables, and this fixed number is less than 16, so we don't end up with a Unique collision.
This ticket is to track several tasks:
- Make sure the analysis above is correct and that we don't have a latent bug.
- Document the situation.
- Look for similar problems with other wired-in things.
- Come up with a way to, e.g.,
ASSERT
that no Unique collisions happen.
Note that if we get this wrong, very subtle problems will arise. (I know, as I once got a wired-in thing wrong in this way. It took a long time to debug.)