Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#11103 closed bug (fixed)

DuplicateRecordFields + TemplateHaskell

Reported by: adamgundry Owned by: adamgundry
Priority: normal Milestone: 8.0.1
Component: Template Haskell Version: 7.11
Keywords: ORF Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D1586
Wiki Page:


The DuplicateRecordFields extension works by mangling the Names of field selector functions, and treating fields specially in the renamer. Thus if you define

data T = MkT { foo :: Int }

then GHC will actually generate a selector called $sel:foo:MkT, but will resolve foo to refer to this selector.

In general we want this name-mangling to be internal only, but at the moment it is visible when using Template Haskell, because the TH AST doesn't have a way to represent the distinction between the selector name and the field label. For example, if you reify ''T above and then pretty-print it you will currently get

data T = MkT { $sel:foo:MkT :: Int }

which is obviously bad.

I'm not sure how best to address this. We could represent the name as mkNameG_v pkg mod "foo", which will look okay when inspected, but if it is subsequently reified it might be ambiguous. Should we add a new NameFlavour?

Change History (5)

comment:1 Changed 4 years ago by adamgundry

Differential Rev(s): Phab:D1586
Status: newpatch

I've proposed a simple change to how reify works for duplicate record fields, which will mean that normal uses of TH continue to work, but that re-reifying the name of a field will fail.

comment:2 Changed 4 years ago by adamgundry

Owner: set to adamgundry

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

In 4b161c93/ghc:

Reify DuplicateRecordFields by label, rather than by selector

See `Note [Reifying field labels]` in `TcSplice`. This makes
typical uses of TH work better with `DuplicateRecordFields`.
If `reify` is called on the `Name` of a field label produced by
the output of a previous `reify`, and there are multiple  fields
with that label defined in the same module, it may fail with
an ambiguity error.

Test Plan:
Added tests, and manually tested that this makes
Aeson's `deriveJSON` avoid the `$sel:` prefixes.

Reviewers: simonpj, goldfire, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision:

GHC Trac Issues: #11103

comment:4 Changed 4 years ago by bgamari

Resolution: fixed
Status: patchclosed

comment:5 Changed 4 years ago by adamgundry

Keywords: ORF added
Note: See TracTickets for help on using tickets.