[GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages

[GHC]

#9049: Expose srcLoc from the assertion architecture to allow better error
messages
-------------------------------------+-------------------------------------
        Reporter:  nh2               |                   Owner:  gridaphobe
            Type:  feature request   |                  Status:  patch
        Priority:  normal            |               Milestone:  7.12.1
       Component:  Compiler          |                 Version:  7.8.2
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:  Phab:D578
-------------------------------------+-------------------------------------

Comment (by Austin Seipp <austin@…>):

 In [changeset:"c024af131b9e2538486eb605ba8af6a8d10fe76d/ghc"]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="c024af131b9e2538486eb605ba8af6a8d10fe76d"
 Expose source locations via Implicit Parameters of type
 GHC.Location.Location

 Summary:
 IPs with this type will always be solved for the current source
 location. If another IP of the same type is in scope, the two locations
 will be
 appended, creating a call-stack. The Location type is kept abstract so
 users
 cannot create them, but a Location can be turned into a list of SrcLocs,
 which
 correspond to individual locations in a program. Each SrcLoc contains a
 package/module/file name and start/end lines and columns.

 The only thing missing from the SrcLoc in my opinion is the name of the
 top-level definition it inhabits. I suspect that would also be useful, but
 it's
 not clear to me how to extract the current top-level binder from within
 the
 constraint solver. (Surely I'm just missing something here?)

 I made the (perhaps controversial) decision to have GHC completely ignore
 the names of Location IPs, meaning that in the following code:

     bar :: (?myloc :: Location) => String
     bar = foo

     foo :: (?loc :: Location) => String
     foo = show ?loc

 if I call `bar`, the resulting call-stack will include locations for

 1. the use of `?loc` inside `foo`,
 2. `foo`s call-site inside `bar`, and
 3. `bar`s call-site, wherever that may be.

 This makes Location IPs very special indeed, and I'm happy to change it if
 the
 dissonance is too great.

 I've also left out any changes to base to make use of Location IPs, since
 there
 were some concerns about a snowball effect. I think it would be reasonable
 to
 mark this as an experimental feature for now (it is!), and defer using it
 in
 base until we have more experience with it. It is, after all, quite easy
 to
 define your own version of `error`, `undefined`, etc. that use Location
 IPs.

 Test Plan: validate, new test-case is
 testsuite/tests/typecheck/should_run/IPLocation.hs

 Reviewers: austin, hvr, simonpj

 Reviewed By: simonpj

 Subscribers: simonmar, rodlogic, carter, thomie

 Differential Revision: https://phabricator.haskell.org/D578

 GHC Trac Issues: #9049
 }}}

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