This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: broken FE diagnostics wrt complex expressions
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: dberlin at dberlin dot org, jakub at redhat dot com, gcc at gcc dot gnu dot org, gdr at integrable-solutions dot net
- Date: Wed, 13 Aug 2008 17:41:18 -0400
- Subject: Re: broken FE diagnostics wrt complex expressions
- References: <20080813175223.GA31009@redhat.com> <m3k5ek67d0.fsf@fleche.redhat.com>
> If you're interested in working on this, I think one way to do it
> would be to start with a parser and make sure it always picks the
> proper token from which to extract a location. This is a reasonable
> amount of work, and unfortunately much of it would have to be complete
> before we could enable caret- or column-output. (I have a few random
> unsubmitted patches toward this direction, I can forward them if you
> are interested.)
Sure, send them my way.
> I suspect that there's some work fixing optimization passes. I have
> not looked but I would not be surprised if some of them pick locations
> poorly when rearranging things.
But this has nothing to do with error messages. I mean, not initially.
Although all this is bound to help Alex, or whomever is working on
proper debug information (I'm guessing).
> My full wish here, getting rid of input_location, requires changes all
> over. E.g., the location should be an argument to build_decl; that
> alone has hundreds of calls.
Well, perhaps we can start one step at a time, hopefully in steps that
can be independently committed-- thus requiring no branch :). Something
like this-- in order:
1. beginning/ending locations functionality as Joseph suggests.
2. make sure the parsers pick the proper token/location.
3. error reporting machinery
How does this sound?
(As is customary with me, I'm doing a lot of hand-waving, because
everything's a 4-5 day job in my mind-- just like tuples. I'm sure
it'll be a can of worms.)
Aldy