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
<simo...@microsoft.com> 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
> | <simo...@microsoft.com> 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:care...@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<simo...@microsoft.com>
> | > | > 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-boun...@haskell.org
> | > | > | [mailto:glasgow-haskell- users-boun...@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-boun...@haskell.org
> | > | > | | [mailto:glasgow-haskell- users-boun...@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/

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

Reply via email to