Opened 10 years ago

Closed 8 years ago

#3715 closed bug (fixed)

GHC API no longer exports location information for error/warning messages

Reported by: greenrd Owned by:
Priority: normal Milestone: 7.2.1
Component: GHC API Version: 6.12.1 RC1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Other Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

scion uses the location information in error/warning Messages for background typechecking (for some reason). It can now (with the 6.12.1 RC2 API) no longer do anything to a Message other than show it, so it would have to re-parse the output of "show" to extract the location information.

Change History (12)

comment:1 Changed 10 years ago by greenrd

In addition, it can no longer show the message in "unqualified" style, because "show" ignores the errMsgContext.

So maybe all the fields of ErrMsg should be exported, to get us back to where we were in 6.10?

comment:2 Changed 10 years ago by simonpj

Can you be 100% concrete?

  • What exactly is the API change that you've encountered? (E.g. there used to be a function getMsgLoc :: Message -> SrcLoc but it disappered in 6.12. Or whatever.)
  • What exactly is the change (or reversion) that would help you?

Simon

comment:3 in reply to:  2 Changed 10 years ago by greenrd

Replying to simonpj:

Can you be 100% concrete?

Yes, sorry.

  • What exactly is the API change that you've encountered?

The fields errMsgSpans, errMsgShortDoc, and errMsgContext of the ErrMsg record in compiler/main/ErrUtils.lhs, used to be exported; now they are not. They are still there (in RC2), just not exported. The first one was used by scion for determining the location associated with a message; the other two were used to display it nicely (see comment 1).

  • What exactly is the change (or reversion) that would help you?

Exporting those fields from ErrUtils.lhs again. I could not find any other way of getting hold of the same information.

comment:4 Changed 10 years ago by igloo

These exports were removed by:

Thu Jul 23 14:01:08 BST 2009  simonpj@microsoft.com
  * Use the ErrMsg record type

Simon, was that deliberate?

comment:5 Changed 10 years ago by simonpj

Owner: set to igloo

Crumbs, its my fault then?!

Ah, hmm. I think I must have noted that these functions were unused in GHC itself, and removed them.

Ian: can you please re-add the exports I removed? I think we can slip this into 6.12.1. It's clearly a glitch.

We should think about how to avoid this in future. That is, a way to answer the question "does this function form part of the advertised GHC API?".

Simon

comment:6 Changed 10 years ago by simonpj

PS thank you for reporting this. Much better to catch this stuff before the release. And apologies for the glitch.

Simon

comment:7 in reply to:  5 Changed 10 years ago by simonmar

Replying to simonpj:

We should think about how to avoid this in future. That is, a way to answer the question "does this function form part of the advertised GHC API?".

If this stuff is used by a client, then we should export it from GHC. Roughly speaking, we should look at clients from time to time to see what they're using that isn't exported from GHC, and decide whether (a) we want to put it there, or (b) we want to expose something else nicer. Eventually the GHC module will be useful enough on its own that we can start hiding the other modules in the GHC package.

comment:8 Changed 10 years ago by igloo

Milestone: 6.14.1

The actual regression is fixed in HEAD and 6.12 by:

Sat Dec  5 15:35:32 GMT 2009  Ian Lynagh <igloo@earth.li>
  * Add some missing exports back for GHC package users; fixes trac #3715

I'll leave the ticket open so we can decide what we want to expose in the GHC module.

comment:9 Changed 10 years ago by igloo

Owner: igloo deleted

comment:10 Changed 9 years ago by igloo

Milestone: 7.0.17.0.2

comment:11 Changed 9 years ago by igloo

Milestone: 7.0.27.2.1

comment:12 Changed 8 years ago by igloo

Resolution: fixed
Status: newclosed

The problem is fixed, so closing the ticket.

Note: See TracTickets for help on using tickets.