[GHC] #15110: Exitification abstracts over shadowed variables

[GHC]

#15110: Exitification abstracts over shadowed variables
-------------------------------------+-------------------------------------
           Reporter:  nomeata        |             Owner:  (none)
               Type:  bug            |            Status:  new
           Priority:  normal         |         Milestone:  8.6.1
          Component:  Compiler       |           Version:  8.5
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 Simon did some code review of `Exitify.hs` in
 https://ghc.haskell.org/trac/ghc/ticket/14152#comment:36 and he was onto
 something; the code is wrong after all:

 Consider this core term
 {{{
   joinrec j (x :: Bool) (x :: Int) =
     if x == 0
     then foo x
     else jump j True (x - 1)
   in …
 }}}
 where the two parameters `x` and `x` are different variables, but shadow
 each other (i.e. have the same unique). This is legal Core!

 But Exitification chooses the variables to abstract over in this line:
 {{{
         -- The possible arguments of this exit join point
         -- No need for `sortQuantVars`, `captured` is already in
 dependency order
         abs_vars = map zap $ filter (`elemVarSet` fvs) captured
 }}}
 where `captured = [x::Bool,x::Int]` in this case, which would yield this
 code

 {{{
   join exit (x :: Bool) (x :: Int) = foo x in
   joinrec j (x :: Bool) (x :: Int) =
     if x == 0
     then jump exit (x::Bool) (x::Int)
     else jump j True (x - 1)
   in …
 }}}
 which is no longer type correct (or even “scope-correct”) any more, as it
 passes the `Int`-typed `x` as the `Bool` argument to `exit`.

 The conditions where this happens, i.e. such shadowing, is rather obscure
 so I did not even try to produce a lint error here. It also means that
 this is rather low severity, but I’ll still go and fix it.

 An application of `reverseNub` seems to be in order – or simply switching
 to keeping `captured` in a `DVarSet` rather than a list (in which case
 `sortQuantVars` would be required…)

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