> 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