This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] GCC caret diagnostics
- From: Tom Tromey <tromey at redhat dot com>
- To: Manuel LÃpez-IbÃÃez <lopezibanez at gmail dot com>
- Cc: "GCC Mailing List" <gcc at gcc dot gnu dot org>
- Date: Fri, 07 Mar 2008 08:54:28 -0700
- Subject: Re: [RFC] GCC caret diagnostics
- References: <firstname.lastname@example.org>
- Reply-to: tromey at redhat dot com
>>>>> "Manuel" == Manuel LÃpez-IbÃÃez <email@example.com> writes:
Manuel> Here is a patch that give us caret diagnostics in C/C++.
Manuel> The third approach would be to store an offset and when
Manuel> generating diagnostics, reopen the file, fseek to the offset
Manuel> and print that line.
I tend to favor this, provided that the performance is not too awful.
But maybe this is painful due to iconv translation?
Ian suggested that we delete this information after the FE is
finished. This makes sense, I think, from a memory-saving
perspective. But, that means we will get different kinds of error
output depending on when a diagnostic is emitted, which I think is
pretty unfriendly -- it exposes implementation details of gcc to the
So, the reason I favor trying the reopen-and-seek approach is that it
would let us keep this information around and be consistent in what we
What do you think of that?
Manuel> It would be nice to have a way to point directly to the
Manuel> beginning of each line: multiple pointers per line_map?
Anything is fine here as long as the total cost of the line map
remains below the threshold of fully expanded locations. IMO.
Manuel> Well, comments, ideas, code, questions, help are all welcome.
How about -fshow-caret instead of -fdiagnostics-show-caret?
(By analogy with -fshow-column.)
With this implementation I think cpp will not emit caret diagnostics.
It ought to as well, IMO -- consistency is important here, I think.
Maybe now it is time to switch cpp to use gcc's diagnostic
machinery... I think all the prerequisites to this have been met,
though I am not sure.