[GHC] #8649: Disambiguate Repeated Identifiers for data types in error messages

[GHC]

#8649: Disambiguate Repeated Identifiers for data types in error messages
-------------------------------------+------------------------------------
        Reporter:  agibiansky        |            Owner:
            Type:  bug               |           Status:  new
        Priority:  normal            |        Milestone:
       Component:  Compiler          |          Version:  7.6.3
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------

Comment (by Simon Peyton Jones <simonpj@…>):

 In [changeset:"73c08ab10e4077e18e459a1325996bff110360c3/ghc"]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="73c08ab10e4077e18e459a1325996bff110360c3"
 Re-work the naming story for the GHCi prompt (Trac #8649)

 The basic idea here is simple, and described in Note [The interactive
 package]
 in HscTypes, which starts thus:

     Note [The interactive package]
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     Type and class declarations at the command prompt are treated as if
     they were defined in modules
        interactive:Ghci1
        interactive:Ghci2
        ...etc...
     with each bunch of declarations using a new module, all sharing a
     common package 'interactive' (see Module.interactivePackageId, and
     PrelNames.mkInteractiveModule).

     This scheme deals well with shadowing.  For example:

        ghci> data T = A
        ghci> data T = B
        ghci> :i A
        data Ghci1.T = A  -- Defined at <interactive>:2:10

     Here we must display info about constructor A, but its type T has been
     shadowed by the second declaration.  But it has a respectable
     qualified name (Ghci1.T), and its source location says where it was
     defined.

     So the main invariant continues to hold, that in any session an
 original
     name M.T only refers to oe unique thing.  (In a previous iteration
 both
     the T's above were called :Interactive.T, albeit with different
 uniques,
     which gave rise to all sorts of trouble.)

 This scheme deals nicely with the original problem.  It allows us to
 eliminate a couple of grotseque hacks
   - Note [Outputable Orig RdrName] in HscTypes
   - Note [interactive name cache] in IfaceEnv
 (both these comments have gone, because the hacks they describe are no
 longer necessary). I was also able to simplify
 Outputable.QueryQualifyName,
 so that it takes a Module/OccName as args rather than a Name.

 However, matters are never simple, and this change took me an
 unreasonably long time to get right.  There are some details in
 Note [The interactive package] in HscTypes.
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8649#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler