
#14630: name shadowing warnings by record pattern synonyms + RecordWildCards or NamedFieldPuns -------------------------------------+------------------------------------- Reporter: mizunashi_mana | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11228, #11970 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): In the past (prior to Phab:D761), the `RecFieldEnv` stored the set of record field names defined in the current module, and `is_shadowed_gre` used this set for local identifiers and `isRecordSelector` for imported identifiers. We could go back to doing something similar. However, in order to implement `DuplicateRecordFields`, it's helpful for a GRE to simply know whether or not it is a record field (and the field label, if it is), because the renamer ends up special-casing the treatment of multiple in-scope GREs when they are all fields. I think we should keep doing this, and moreover make it correct for record pattern synonym fields, as a step towards #11228. That is, I think we should do something like Ryan's patch. The price we end up paying is a slightly more complicated definition of `AvailInfo`, but I don't think that's too terrible, is it?
I would imagine two distinct data types, one which tracks parenthood and and one which tracks whether a GRE is a record field.
Yes, I think this would be worth doing instead of a new constructor in `Parent`. In the presence of record pattern synonyms, these two properties are independent, and they could simply be two separate fields of `GlobalRdrElt`. Unfortunately I doubt we can really make things fundamentally simpler without doing away with `DuplicateRecordFields` altogether; the simplifications I'm considering will move work from the typechecker to the renamer, but the issues here are all about the renamer. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14630#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler