[GHC] #12699: Suspicious treatment of renaming of field labels
GHC
ghc-devs at haskell.org
Thu Oct 13 23:52:24 UTC 2016
#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
More information about the ghc-tickets
mailing list