One bit of experience from my Maple days: we made it a policy to create regression tests for every single bug we fixed. No bug could be marked closed without an identifier for the test that makes sure this does not revert. This seemed like too much at first, but over the years, we were always glad of this. We caught all sorts of very strange bugs because of doing this. This is especially valuable for very long-lived software (like GHC), where the time-span between the last time the problem showed up and when it occurs again can be 15+ years. In other words, I am saying that even though in the present context this feature/bug can seem small, it is extremely hard to predict what context will be true in 10+ years, where this regression may become a symptom of something bigger. Jacques On 05/06/2012 8:36 AM, Simon Peyton-Jones wrote:

Done. I don't think it's worth a regression test.

SImon

commit cb705a38d677e2ab4cad37447c8180bd397d5576 Author: Simon Peyton Jones Date: Tue Jun 5 13:35:07 2012 +0100

Add sensible locations to record-selector bindings

compiler/typecheck/TcTyClsDecls.lhs | 26 +++++++++++++------------- 1 files changed, 13 insertions(+), 13 deletions(-)

| -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Simon Peyton-Jones | Sent: 05 June 2012 12:38 | To: JP Moresmau; glasgow-haskell-users@haskell.org | Subject: RE: Source Location of DataCon objects in GHC 7.4.1 API | | Ah I see. I'm fixing this. | | Simon | | | -----Original Message----- | | From: glasgow-haskell-users-bounces@haskell.org | | [mailto:glasgow-haskell- users-bounces@haskell.org] On Behalf Of JP | | Moresmau | | Sent: 01 June 2012 10:25 | | To: glasgow-haskell-users@haskell.org | | Subject: Source Location of DataCon objects in GHC 7.4.1 API | | | | Hello | | | | I have a failing test in BuildWrapper when moving from GHC 7.0.4 to | | 7.4.1. As far I can tell, in the TypecheckedSource I get DataCon | | objects that have no location info, and hence I can't retrieve them by | | location... Which is useful in a IDE (tell me what's under my mouse | | cursor, tell me where else it's used). | | | | Given the simple data declaration: | | data DataT=MkData {name :: String} | | | | In 7.0.4 I obtain a hierarchy that ends in FunBind (on a Var called | | "name")/MatchGroup/Match/ConPatOut and the contained DataCon named | | "MkData" has a SrcSpan associated with it, and so do the Var, | | MatchGroup and Match. | | In 7.4.1 I have the same hierarchy but the DataCon tells me "no | | location info". The Var "name" has a location, but the MatchGroup and | | Match don't either. | | | | Is it a normal change? Do I need to change something in the way I load | | the module? Is it a regression? | | | | Thanks! | | | | -- | | JP Moresmau | | http://jpmoresmau.blogspot.com/ | | | | _______________________________________________ | | Glasgow-haskell-users mailing list | | Glasgow-haskell-users@haskell.org | | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

I haven't had time yet to create the Trac incident for that, with a test case detailing what I've said in the mail. This is not minor for me. It will mean that users of EclipseFP won't see the types of constructors when they hover over it, but more importantly that the new features of EclipseFP (Haskell-aware searching and replace) won't work for constructors. I know I haven't been good before following up on my bug reports all simply because I'm on Windows and I just don't have the time to set up a build machine that I can validate fixes on by building GHC from source myself. So I'm usually waiting for a HP release and by then it's too late. Or can I get windows builds from somewhere? Thanks anyway for fixing the issue so quickly, I will try to work on the trac issue asap. JP On Tue, Jun 5, 2012 at 2:49 PM, Simon Peyton-Jones wrote:

That's our policy too, as you will see if you look at any closed Trac ticket.  We have thousands of regression tests, and they are fabulously useful.  But it's a judgement call when the scope is extremely narrow and the regression test is hard to make, and I decided not to.

By all means submit a regression test for this one; I'll gladly commit it.

S

| -----Original Message----- | From: Jacques Carette [mailto:carette@mcmaster.ca] | Sent: 05 June 2012 13:45 | To: Simon Peyton-Jones | Cc: JP Moresmau; glasgow-haskell-users@haskell.org | Subject: Re: Source Location of DataCon objects in GHC 7.4.1 API | | One bit of experience from my Maple days: we made it a policy to create | regression tests for every single bug we fixed.  No bug could be marked | closed without an identifier for the test that makes sure this does not | revert. | | This seemed like too much at first, but over the years, we were always | glad of this.  We caught all sorts of very strange bugs because of doing | this.  This is especially valuable for very long-lived software (like | GHC), where the time-span between the last time the problem showed up | and when it occurs again can be 15+ years. | | In other words, I am saying that even though in the present context this | feature/bug can seem small, it is extremely hard to predict what context | will be true in 10+ years, where this regression may become a symptom of | something bigger. | | Jacques | | On 05/06/2012 8:36 AM, Simon Peyton-Jones wrote: | > Done.  I don't think it's worth a regression test. | > | > SImon | > | > commit cb705a38d677e2ab4cad37447c8180bd397d5576 | > Author: Simon Peyton Jones | > Date:   Tue Jun 5 13:35:07 2012 +0100 | > | >      Add sensible locations to record-selector bindings | > | >   compiler/typecheck/TcTyClsDecls.lhs |   26 +++++++++++++------------ | - | >   1 files changed, 13 insertions(+), 13 deletions(-) | > | > | -----Original Message----- | > | From: glasgow-haskell-users-bounces@haskell.org | > | [mailto:glasgow-haskell- users-bounces@haskell.org] On Behalf Of | > | Simon Peyton-Jones | > | Sent: 05 June 2012 12:38 | > | To: JP Moresmau; glasgow-haskell-users@haskell.org | > | Subject: RE: Source Location of DataCon objects in GHC 7.4.1 API | > | | > | Ah I see.  I'm fixing this. | > | | > | Simon | > | | > | | -----Original Message----- | > | | From: glasgow-haskell-users-bounces@haskell.org | > | | [mailto:glasgow-haskell- users-bounces@haskell.org] On Behalf Of | > | | JP Moresmau | > | | Sent: 01 June 2012 10:25 | > | | To: glasgow-haskell-users@haskell.org | > | | Subject: Source Location of DataCon objects in GHC 7.4.1 API | > | | | > | | Hello | > | | | > | | I have a failing test in BuildWrapper when moving from GHC 7.0.4 | > | | to 7.4.1. As far I can tell, in the TypecheckedSource I get | > | | DataCon objects that have no location info, and hence I can't | > | | retrieve them by location... Which is useful in a IDE (tell me | > | | what's under my mouse cursor, tell me where else it's used). | > | | | > | | Given the simple data declaration: | > | | data DataT=MkData {name :: String} | > | | | > | | In 7.0.4 I obtain a hierarchy that ends in FunBind (on a Var | > | | called "name")/MatchGroup/Match/ConPatOut and the contained | > | | DataCon named "MkData" has a SrcSpan associated with it, and so do | > | | the Var, MatchGroup and Match. | > | | In 7.4.1 I have the same hierarchy but the DataCon tells me "no | > | | location info". The Var "name" has a location, but the MatchGroup | > | | and Match don't either. | > | | | > | | Is it a normal change? Do I need to change something in the way I | > | | load the module? Is it a regression? | > | | | > | | Thanks! | > | | | > | | -- | > | | JP Moresmau | > | | http://jpmoresmau.blogspot.com/ | > | | | > | | _______________________________________________ | > | | Glasgow-haskell-users mailing list | > | | Glasgow-haskell-users@haskell.org | > | | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | | > | | > | | > | _______________________________________________ | > | Glasgow-haskell-users mailing list | > | Glasgow-haskell-users@haskell.org | > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | > | > | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users@haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

-- JP Moresmau http://jpmoresmau.blogspot.com/

Ticket #6145 created. I've attached to the ticket a sample file that exhibit the issue by loading sample code and printing True if it finds the valid SrcSpan, False otherwise. Thanks very much. JP On Tue, Jun 5, 2012 at 3:37 PM, Simon Peyton-Jones wrote:

| late. Or can I get windows builds from somewhere?

Nightly snapshots are here: http://www.haskell.org/ghc/dist/current/dist/

Look for the latest "mingw" build

S

| | Thanks anyway for fixing the issue so quickly, I will try to work on the | trac issue asap. | | JP | | On Tue, Jun 5, 2012 at 2:49 PM, Simon Peyton-Jones | wrote: | > That's our policy too, as you will see if you look at any closed Trac | ticket.  We have thousands of regression tests, and they are fabulously | useful.  But it's a judgement call when the scope is extremely narrow | and the regression test is hard to make, and I decided not to. | > | > By all means submit a regression test for this one; I'll gladly commit | it. | > | > S | > | > | -----Original Message----- | > | From: Jacques Carette [mailto:carette@mcmaster.ca] | > | Sent: 05 June 2012 13:45 | > | To: Simon Peyton-Jones | > | Cc: JP Moresmau; glasgow-haskell-users@haskell.org | > | Subject: Re: Source Location of DataCon objects in GHC 7.4.1 API | > | | > | One bit of experience from my Maple days: we made it a policy to | > | create regression tests for every single bug we fixed.  No bug could | > | be marked closed without an identifier for the test that makes sure | > | this does not revert. | > | | > | This seemed like too much at first, but over the years, we were | > | always glad of this.  We caught all sorts of very strange bugs | > | because of doing this.  This is especially valuable for very | > | long-lived software (like GHC), where the time-span between the last | > | time the problem showed up and when it occurs again can be 15+ | years. | > | | > | In other words, I am saying that even though in the present context | > | this feature/bug can seem small, it is extremely hard to predict | > | what context will be true in 10+ years, where this regression may | > | become a symptom of something bigger. | > | | > | Jacques | > | | > | On 05/06/2012 8:36 AM, Simon Peyton-Jones wrote: | > | > Done.  I don't think it's worth a regression test. | > | > | > | > SImon | > | > | > | > commit cb705a38d677e2ab4cad37447c8180bd397d5576 | > | > Author: Simon Peyton Jones | > | > Date:   Tue Jun 5 13:35:07 2012 +0100 | > | > | > | >      Add sensible locations to record-selector bindings | > | > | > | >   compiler/typecheck/TcTyClsDecls.lhs |   26 | > | > +++++++++++++------------ | > | - | > | >   1 files changed, 13 insertions(+), 13 deletions(-) | > | > | > | > | -----Original Message----- | > | > | From: glasgow-haskell-users-bounces@haskell.org | > | > | [mailto:glasgow-haskell- users-bounces@haskell.org] On Behalf Of | > | > | Simon Peyton-Jones | > | > | Sent: 05 June 2012 12:38 | > | > | To: JP Moresmau; glasgow-haskell-users@haskell.org | > | > | Subject: RE: Source Location of DataCon objects in GHC 7.4.1 API | > | > | | > | > | Ah I see.  I'm fixing this. | > | > | | > | > | Simon | > | > | | > | > | | -----Original Message----- | > | > | | From: glasgow-haskell-users-bounces@haskell.org | > | > | | [mailto:glasgow-haskell- users-bounces@haskell.org] On Behalf | > | > | | Of JP Moresmau | > | > | | Sent: 01 June 2012 10:25 | > | > | | To: glasgow-haskell-users@haskell.org | > | > | | Subject: Source Location of DataCon objects in GHC 7.4.1 API | > | > | | | > | > | | Hello | > | > | | | > | > | | I have a failing test in BuildWrapper when moving from GHC | > | > | | 7.0.4 to 7.4.1. As far I can tell, in the TypecheckedSource I | > | > | | get DataCon objects that have no location info, and hence I | > | > | | can't retrieve them by location... Which is useful in a IDE | > | > | | (tell me what's under my mouse cursor, tell me where else it's | used). | > | > | | | > | > | | Given the simple data declaration: | > | > | | data DataT=MkData {name :: String} | > | > | | | > | > | | In 7.0.4 I obtain a hierarchy that ends in FunBind (on a Var | > | > | | called "name")/MatchGroup/Match/ConPatOut and the contained | > | > | | DataCon named "MkData" has a SrcSpan associated with it, and | > | > | | so do the Var, MatchGroup and Match. | > | > | | In 7.4.1 I have the same hierarchy but the DataCon tells me | > | > | | "no location info". The Var "name" has a location, but the | > | > | | MatchGroup and Match don't either. | > | > | | | > | > | | Is it a normal change? Do I need to change something in the | > | > | | way I load the module? Is it a regression? | > | > | | | > | > | | Thanks! | > | > | | | > | > | | -- | > | > | | JP Moresmau | > | > | | http://jpmoresmau.blogspot.com/ | > | > | | | > | > | | _______________________________________________ | > | > | | Glasgow-haskell-users mailing list | > | > | | Glasgow-haskell-users@haskell.org | > | > | | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | > | | > | > | | > | > | | > | > | _______________________________________________ | > | > | Glasgow-haskell-users mailing list | > | > | Glasgow-haskell-users@haskell.org | > | > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | > | > | > | > | > | > | > _______________________________________________ | > | > Glasgow-haskell-users mailing list | > | > Glasgow-haskell-users@haskell.org | > | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | | > | > | | | | -- | JP Moresmau | http://jpmoresmau.blogspot.com/

-- JP Moresmau http://jpmoresmau.blogspot.com/