This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: broken FE diagnostics wrt complex expressions


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]