#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