Opened 4 years ago

Last modified 2 years ago

#11228 new bug

Interaction between ORF and record pattern synonyms needs to be resolved.

Reported by: mpickering Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.11
Keywords: PatternSynonyms, orf Cc: adamgundry, akio, gridaphobe
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: #9975, #11283 Differential Rev(s):
Wiki Page:


Currently the two extensions do not work well together. When defining a record pattern synonym all field names must be distinct even with the extension turned on.

Change History (7)

comment:1 Changed 4 years ago by bgamari


comment:2 Changed 4 years ago by adamgundry

Cc: adamgundry added; agundry removed
Owner: set to adamgundry

I'll try to take another look at this soon.

(Sadly I didn't spot this ticket earlier, because I need to be CCd as adamgundry rather than agundry.)

comment:3 Changed 4 years ago by adamgundry

It turns out that trying to make use of duplicate fields belonging to pattern synonyms triggers a find_tycon panic, similar to #9975.

comment:4 Changed 4 years ago by adamgundry

Owner: adamgundry deleted

The panic was actually caused by the combination of pattern synonyms and DisambiguateRecordFields or RecordWildCards, without needing DuplicateRecordFields. See #11283.

The more general question of the interaction of DuplicateRecordFields and record pattern synonyms looks like it will be rather intricate. At the moment, record pattern synonym constructors and fields are not distinguished by the Avail or Parent types, but constructors and fields will need to be handled differently. This will require significant refactoring.

We need to track the pattern synonym to which a field belongs, so that we can disambiguate fields properly. This doesn't even require DuplicateRecordFields: merely using DisambiguateRecordFields fails when the constructor is a record pattern synonym. However, the pattern synonym isn't a "parent" for the field in the same way that a datatype is. And pattern synonyms have the added complexity of being able to be associated with arbitrary parent datatypes.

In addition, once DuplicateRecordFields is involved we need to keep track of the FieldLabelString separately from the Name when representing fields (e.g. in AvailTC or FldParent).

I'm not going to be able to address this in the near future.

comment:5 Changed 4 years ago by Ben Gamari <ben@…>

In 4f69203d/ghc:

Fix panic when using pattern synonyms with DisambiguateRecordFields

This fixes a `find_tycon` panic when constructing a record pattern
synonym when `DisambiguateRecordFields` (turned on by `RecordWildCards`)
is enabled.  The handling of record wild cards in such constructions
isn't completely satisfactory, but doing better will require the
`Parent` type to be more informative, as I'll explain on #11228.

Test Plan: New test patsyn/should_compile/T11283.hs

Reviewers: mpickering, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision:

GHC Trac Issues: #11283

comment:6 Changed 3 years ago by akio

Cc: akio added

comment:7 Changed 2 years ago by gridaphobe

Cc: gridaphobe added
Note: See TracTickets for help on using tickets.