[GHC] #14293: View patterns with locally defined functions in restructuring don't compile

[GHC]

#14293: View patterns with locally defined functions in restructuring don't compile
-------------------------------------+-------------------------------------
        Reporter:  heisenbug         |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.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):

 I looked into this yesterday, but this seems much harder to fix than I
 would have originally thought.

 The issue is that we rename top-level bindings in two phases:

 1. First, we rename the LHSes of each top-level binding, and gather up the
 names of each binding form.
 2. We then extend the global `RdrEnv` with these binding forms and proceed
 to rename the RHSes of each top-level binding.

 The problem concerns what constitutes a "LHS". For `FunBind`s, like `foo`
 and `bar`, the LHS is just the name of the function itself. As a result,
 the RHS of `bar` includes its `(foo -> res)` pattern, so by the time the
 RHS is renamed, `foo` is already in scope.

 For `PatBind`s, however, the LHS includes the pattern itself. This is out
 of necessity, since for example, `Just (foo -> res')` is binding `res'` at
 the top level, so we must dig into the pattern itself in order to rename
 `res'`. But that means that when we are renaming `Just (foo -> res')`, we
 haven't yet brought `foo` into scope in the `RdrEnv`, causing the error
 observed in this ticket.

 This is quite a sticky situation, and I'm not sure it's easy to resolve.
 Perhaps there's some sort of SCC analysis that could save us here? I'll
 have to defer to the wisdom of those who know more about the renamer than
 I do.

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