[GHC] #15149: Identical distinct type family fields miscompiled

[GHC]

#15149: Identical distinct type family fields miscompiled
-------------------------------------+-------------------------------------
        Reporter:  NeilMitchell      |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.4.2
      Resolution:                    |             Keywords:  ORF
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  GHC rejects       |  Unknown/Multiple
  valid program                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 > It would probably be simpler to defer all field resolution to the type-
 checker, though we've also considered going in the opposite direction, and
 moving all field resolution back to the renamer

 That proposal (!DuplicateRecordFields simplification) is about simplifying
 the DRF spec. Yes, it'd make it possible to resolve that particular aspect
 of record fields in the renamer -- but it by no means requires us to do
 so.

 > That is, using them inside a TH bracket will fail with a "not supported"
 error

 My baseline thought is that `C { x = e1, y = e2 }` should have `x` and `y`
 as `OccNames` right up to the type checker. And that would be so in TH
 syntax to.  In TH we have
 {{{
 data Exp = ... | RecConE [FieldExp]
 type FieldExp = (Name,Pat)
 }}}
 We could consider changing that `Name` to `OccName`, or just using the
 `NameS` variant of `Name`.  No serious problem there.

 My notion of using `OccName` is a bit ''too'' simple.

 * It is in principle fine for `C { ... }` in both expressions and
 patterns, but in fact H98 syntax allows a qualified name there, thus `C {
 M.x = e }`.  That suggests we need a `RdrName` there, not an `OccName`.
 The type checker can still resolve it, since the name to the LHS of the
 `=` need consider only the top-level `GlobalRdrEnv` and that is entirely
 available in the typechecker.

 * For record update `e { x = e2 }`, the same applies but now the use of
 qualified names to disambiguate is more important still.

 I think this boils down to

 * Remove the `extFieldOcc` field of `data FieldOcc`, leaving only a
 `Located RdrName`.  (In fact we can then inline `FieldOcc`.)
 * Move the lookup machinery from the renamer to the typechecker

 Do you think that'd work?  Any motivation to try it?

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