[GHC] #13959: substTyVar's definition is highly dubious

[GHC]

#13959: substTyVar's definition is highly dubious
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by RyanGlScott):

 Well looking at the definition of `mkVarSet`, it's no surprise that things
 are going awry:

 {{{#!hs
 mkVarSet :: [Var] -> VarSet
 mkVarSet = mkUniqSet

 mkUniqSet :: Uniquable a => [a]  -> UniqSet a
 mkUniqSet = foldl' addOneToUniqSet emptyUniqSet
 }}}

 It's just grabbing the `Unique` of each type variable, and nothing more.

 Experimentally, when I tried a debugging build of GHC with the modified
 version of `substTyVar`, it fell over trying to compile
 `Data.Type.Equality`. I don't have the full assertion failure at the
 moment, but I recall that there were indeed more `tenvFVs` than what were
 contained in the `in_scope` set.

 [http://git.haskell.org/ghc.git/blob/1ee49cb11c7ad1af20c117a5395df96ded9a729f:/compiler/typecheck/TcGenDeriv.hs#l1686
 Here's] a sample call to `mkVarSet` that's propagated through to
 `substTyVars`. This is used in the logic for `GeneralizedNewtypeDeriving`,
 where we need to take all the type variables mentioned in the instance
 head in preparation for the substitution that substitutes the class tyvars
 with the types used when deriving the instance.

 ...Although now that I think about it, this probably isn't a very good
 example of the thing we're worried about in this ticket, since that
 substitution is formed by simply zipping the class tyvars with their
 instantiated types in the instance, so there's no need to ever substitute
 in the kind of a tyvar... I think.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13959#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler