[GHC] #8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error

[GHC]

#8714: ExistentialQuantification plus DeriveDataTypeable leads to core lint error
-------------------------------------+----------------------------------
        Reporter:  CoreyOConnor      |            Owner:
            Type:  bug               |           Status:  new
        Priority:  normal            |        Milestone:
       Component:  Compiler          |          Version:  7.6.3
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  x86_64 (amd64)
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+----------------------------------

Comment (by goldfire):

 I've tracked this one down, I know exactly what's going wrong, and I know
 how to fix this particular case, but I'm worried that this may be
 representative of a class of errors, and I'm not sure how to fix the lot
 of them.

 The problem is that !SetLevels, while doing various core transformations
 (which I don't yet understand), builds up a substitution. This subst is
 applied as the `CoreExpr` tree is traversed. But, some bits are crucially
 left out. The bug in this report is because the binder of a `case`
 statement is left out -- its type is a type variable, but the type
 variable is substed during the transformation. The result: a binder whose
 type contains an out-of-scope type variable.

 The solution, of course, is to make sure to apply the subst to the
 binder's type. For example, the following works:

 {{{
   = do { let substed_bndr = setVarType case_bndr (substTy (le_subst env)
 (varType case_bndr))
              case_bndr' = TB substed_bndr bndr_spec
 }}}

 These lines should be in place of the current line 385, which sets
 `case_bndr'` without a subst. But, a casual look around tells me that
 lambda-bound binders are also seemingly left out of the substitution, and
 I see that there is a `cloneVar` function which seems to be applying the
 subst. Perhaps the fix should use `cloneVar`. In any case, there's more
 going on here than I feel comfortable fiddling with, but a cognoscente
 should be able to use my detective work to squash the bug in rather little
 time.

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