This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Better GCC diagnostics
- From: "Manuel López-Ibáñez" <lopezibanez at gmail dot com>
- To: "Chris Lattner" <clattner at apple dot com>
- Cc: "GCC Development" <gcc at gcc dot gnu dot org>, "Aldy Hernandez" <aldyh at redhat dot com>, "Tom Tromey" <tromey at redhat dot com>, "Gabriel Dos Reis" <gdr at integrable-solutions dot net>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Fri, 15 Aug 2008 17:43:10 +0200
- Subject: Re: Better GCC diagnostics
- References: <6c33472e0808150709u9420a23s6391cbc669c8c562@mail.gmail.com> <BFDB684A-A12E-4347-8987-082986563BB4@apple.com>
2008/8/15 Chris Lattner <clattner@apple.com>:
>> D) Printing Ranges. This requires:
>>
>> *) Printing accurate column information. Similar to (B) above.
>>
>> *) A location(s) -> source strings interface and machinery. Similar
>> to (A.3) above.
>
> Ranges also require some way to get the end of a token (in addition to its
> beginning). For example, a range for:
>
> X + some_long\
> _ident??/
> ifier
>
> The range should start at "X" and end at "r". This is just a location like
> any other, but requires passing down like the begin loc. You might instead
> decide to do some fuzzy matching or something, but clang at least gets this
> right. This is important for other clients of the loc info, e.g.
> refactoring clients.
Oh yes. Well, there is a lot of fine-tunning to do but I think that
would be covered by A.1 and the binary_op expression would have at
least two locations begin/end pointing to X and r. If we are able to
print ({break;}), in the example I gave earlier, then we will be able
to print nice ranges most of the time.
Cheers,
Manuel.