#12699: Suspicious treatment of renaming of field labels -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -4,2 +4,2 @@ - renamed), renaming them causes `bkpreex06` to fail with the panic - `find_lbl missing foo`. + renamed), renaming them (in `RnModIface`) causes `bkpreex06` to fail with + the panic `find_lbl missing foo`. New description: While working on my rework of interface file names (Phab:D2467) I noticed that there is some funniness in the treatment of renaming field selectors. Namely, `ifaceConDeclFields` are `IfaceTopBndr`s (and should therefore be renamed), renaming them (in `RnModIface`) causes `bkpreex06` to fail with the panic `find_lbl missing foo`. Looking at the environment reveals that there are selectors named `foo` in scope, but they were not renamed. I believe this is due to the implementation of `tcIfaceDataCons`, which typechecks the fields with `mapM (traverse lookupIfaceTop) (ifaceConDeclFields if_cons)`. In essence, this projects the field labels back to `OccName`s (in `ifaceConDeclFields`) and then looks each of these `OccName`s up in the name cache, thereby retrieving the un-renamed `Name`. This seems wrong. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12699#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler