handling of TAB in column number

[Tom Tromey]

>>>>> "Arnaud" == Arnaud Charlet <charlet@adacore.com> writes:

Arnaud> Alternatively we could have an option, but that would be overkill IMO.

Yeah.  It is a mess :-(

Tom> If you're interested in locations, I have a couple other unfinished
Tom> location patches that could use some attention.  One is an attempt to
Tom> fix all the errors in libcpp to use the correct location.  The other is
Tom> a patch to include macro expansion information in a location_t.

Arnaud> I'm working on generating cross-ref info from GCC for C/C++
Arnaud> sources.  So I'm not too interested directly in error location
Arnaud> (your first patch above), but the second patch you mention might
Arnaud> be of interest indeed, can you please send it to me? I'm not
Arnaud> sure I understand what 'include macro expansion info in a
Arnaud> location_t' means exactly, so I'm curious.

Arnaud> Also, what about column info in libcpp itself, in particular
Arnaud> when handling macros? It seems that when e.g. the define() or
Arnaud> used_define() callbacks are called, the only useful sloc info
Arnaud> stored in input_location (itself kind of deprecated as I
Arnaud> understand it) is the current line, with column 0.  Might
Arnaud> actually be related to your first patch mentioned above?

I've attached both patches.

I wrote the error location one long enough ago that I don't really
remember what exactly it does.  It does seem to improve locations in
libcpp in ways not directly affecting error output, so it might be
useful.

What "include macro expansion info in a location_t" means is that a
token arising from macro expansion carries two locations, one indicating
the logical source location (where the expansion occurred) and one
indicating the token's "physical" location (where the macro was defined,
or the location of a token in an actual argument).  My goal here is to
have GCC emit error messages that track macro expansion, in an attempt
to expose better information to users.  (Later I thought of a possible
secondary goal: to let users debug into very large macros like those
appearing in GCC.  However, I have made no attempt at implementing
this.)

Both of these patches are fairly buggy.  I hope to get to them again
someday, but... yeah.  Feel free to take whatever you can use from them.

Tom

-------------- next part --------------
A non-text attachment was scrubbed...
Name: full-libcpp-columns.diff
Type: text/x-patch
Size: 137616 bytes
Desc: libcpp error patch
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20091115/8f96e58d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: macro-locs.diff
Type: text/x-patch
Size: 45352 bytes
Desc: macro locations
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20091115/8f96e58d/attachment-0001.bin>