[GHC] #8649: Disambiguate Repeated Identifiers for data types in error messages
#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 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If, in an interactive context, you redefine a type, but then try to use functions for the previous definition, it will (as expected) give you an error message. The following code would trigger this in an interactive context: {{{ data X = Y Int f (Y i) = i data X = Y Int | Z String f (Y 3) }}} However the error message is not very good: {{{ Couldn't match expected type `:Interactive.X' with actual type `:Interactive.X' }}} This is very uninformative to the user if they do not understand what's going on. The following GHC API code can replicate this: {{{ runDeclsWithLocation "Interactive.hs" 1 "data X = Y Int" runDeclsWithLocation "Asdf.hs" 2 "f (Y i) = i" runDeclsWithLocation "Bloop.hs" 3 "data X = Y Int | Z String" runStmtWithLocation "Test.hs" 4 "f (Y 3)" RunToCompletion }}} Note that varying the location given to `runStmt` and `runDecls` (the string as well as the line number) seems to have no effect upon anything. I started out with just "<interactive>" but varied it to check - no effect on anything as far as I can tell. How can I make this error message more informative? I would ideally like something like {{{ Couldn't match expected type `:Interactive1.X' with actual type `:Interactive5.X' }}} or really anything that caused these types to be visibly different. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8649> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#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
#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:"5e8e8e6e62c5826133c053cd78bb35e9b4aaa05b/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="5e8e8e6e62c5826133c053cd78bb35e9b4aaa05b" Changes in error messages when fixing Trac #8649 Mostly improvements, happily }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8649#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#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:"d63acc8fd99553b2fcca02b58519877827b913ac/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="d63acc8fd99553b2fcca02b58519877827b913ac" Test Trac #8649 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8649#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#8649: Disambiguate Repeated Identifiers for data types in error messages ---------------------------------------+----------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: ghci/scripts/T8649 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by simonpj): * status: new => closed * testcase: => ghci/scripts/T8649 * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8649#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#8649: Disambiguate Repeated Identifiers for data types in error messages ---------------------------------------+----------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: ghci/scripts/T8649 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"28e8d878b63d06824001ac3a631254679e0f1960/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="28e8d878b63d06824001ac3a631254679e0f1960" Simplify handling of the interactive package; fixes Trac #8831 This patch is really a fix to the big commint 73c08ab10e4077e18e459a1325996bff110360c3 Re-work the naming story for the GHCi prompt (Trac #8649) which introduced the 'interactive' package See Note [The interactive package] in HscTypes The original commit set both (a) The tcg_mod field of TcGblEnv to 'interactive:Ghci4' (say) (b) The thisPackage field of DynFlags to 'interactive' But the second step interacts badly with linking. :loaded modules are in the package set by 'thisPackage' (usually 'main'); if you change that, then we try to link package 'main', but can't find it, and that is what happened in #8831. The fix was simple: do (a) but not (b). I changed Note [The interactive package] in HscTypes to describe this. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8649#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
participants (1)
-
GHC