[GHC] #12699: Suspicious treatment of renaming of field labels

[GHC]

#12699: Suspicious treatment of renaming of field labels
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:  adamgundry
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler (Type    |              Version:  8.1
  checker)                           |
      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 adamgundry):

 I don't really understand what is going on here with the interface
 renaming, unfortunately.

 The basic idea of the `DuplicateRecordFields` implementation is that we
 distinguish the `FieldLabelString`/`OccName` of a field from the `Name` of
 a record selector. For example, `data T = MkT { foo :: Int }` gives rise
 to a `FieldLabelString` `foo` whose selector `Name` is `$sel:foo:MkT`.

 Perhaps `ifConFields :: [IfaceTopBndr]` is the wrong type? I suspect it
 should originally have been `[FieldLabelString]`, i.e. the old code
 treated the `[OccName]` as a list of field labels (and hence had to look
 up the selectors corresponding to the labels in `tcIfaceDataCons`). Note
 that record selectors are not implicit TyThings, i.e. they have their own
 `IfaceDecl`s separate from the `IfaceDecl` of the datatype.

 Following Phab:D2467 I wonder if the right thing is to have `ifConFields
 :: [FieldLabel]` or `[FieldLbl IfaceTopBndr]`, so that interface files
 would store both the `FieldLabelString` and selector `Name` (avoiding
 duplication when the former can be derived from the latter)? That would
 allow the selector name to be renamed without affecting the label, and we
 could get rid of the `find_lbl` lookup business in `tcIfaceDataCons`.

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