Hi Alan, I certainly made a few changes to the renamer as part of the ORF work, but I wouldn't expect them to cause the behaviour you describe. Name resolution for ambiguous record selectors is deferred to the typechecker when the DuplicateRecordFields extension is enabled, but unambiguous selectors (as in your example) are resolved by the renamer. Moreover, I didn't touch anything to do with uniques. The record selector will be in scope once, with a single Name containing a single Unique. Unfortunately, I can't reproduce the behaviour you describe with: ghc-8.0.0.20160204 Field1.hs -ddump-rn-trace -dppr-debug Can you describe in more detail how to reproduce the problem? All the best, Adam On 23/02/16 13:35, Alan & Kim Zimmerman wrote:
I am working on updating HaRe for GHC 8.0.1, and have hit an issue with the following file
--------------------------- module Field1 where
--Rename field name 'pointx' to 'pointx1'
data Point = Pt {pointx, pointy :: Float}
absPoint :: Point -> Float absPoint p = sqrt (pointx p * pointx p + pointy p * pointy p) --------------------------
It seems that after the renamer, each of the three instances of `pointx` has a different `nameUnique` value.
Is this because the final resolution is now done during type checking? If so it makes the RenamedSource much harder to work with.
Alan
-- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/