#14848: -XDuplicateRecordFields breaks record expression splices -------------------------------------+------------------------------------- Reporter: dailectic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: ORF Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11103 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * related: => #11103 Comment: I've just rediscovered this issue, and the interaction between `DuplicateRecordFields` and `TemplateHaskell` definitely needs to be addressed more carefully. The problem here is the case for `HsRecFld` in `DsMeta.repE`, which simply replaces the field occurrence with the selector function (which has an internal name that cannot be spliced in, namely `Name "$sel:x:A" (NameG VarName pkg "Lib")`). There are other related problems in `DsMeta` for representing fields in record definition, construction and pattern matching. The way #11103 dealt with a similar problem in reification was to represent field names using a specially-crafted `NameQ`, rather than a `NameG`. In this example that approach would give `Name "x" (NameQ "Lib")` instead. Note that `NameG` cannot be used with the field label in place of the selector, because that leads to looking up an Orig name that doesn't exist. However, while using `NameQ` should fix this example, it doesn't work in general: it means the name is dynamically bound, but of course the field might not be in scope when the splice is run. For a concrete example of this, consider a tiny variant of the test case from #12993: {{{#!hs {-# LANGUAGE DuplicateRecordFields #-} {-# LANGUAGE TemplateHaskell #-} module T12993_Lib (q) where data X = X { x :: Int } q = [|x|] }}} {{{#!hs {-# LANGUAGE TemplateHaskell #-} module T12993 where import T12993_Lib f = $(q) }}} This currently fails with an "Illegal variable name" error similar to the original report from this ticket. With the `NameQ` approach, it would still fail because `x` is not in scope in `T12993`. It seems fairly clear to me that dealing with this properly requires extending the TH AST in some way. The least invasive option might be to extend `NameFlavour` with a new constructor for field names, which would be rather like `NameG` but would carry the selector name. I'm not sure if there are better designs, however. What is the process for proposing/discussing such changes to TH? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14848#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler