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

[greenrd]

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.

[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?

[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

[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.

[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?

[simonpj]

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

[simonpj]

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

Simon

[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.

[igloo]

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.

[igloo]

The problem is fixed, so closing the ticket.