This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] GCC caret diagnostics
On 07/03/2008, Tom Tromey <tromey@redhat.com> wrote:
> >>>>> "Manuel" == Manuel López-Ibáñez <lopezibanez@gmail.com> writes:
> 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?
How should a file be properly opened within GCC? I find the code in
libcpp/files.c pretty confusing and also I am not interested in
parsing the file, so some of the conversions it makes are probably
superflous (or perhaps even impossible when calling from
expand_location).
> How about -fshow-caret instead of -fdiagnostics-show-caret?
> (By analogy with -fshow-column.)
Well, we have -fdiagnostics-show-option and
-fdiagnostics-show-location. So 2 versus 1. ;-) That said, I would
also prefer -fshow-option and -fshow-location.
> 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.
cpp has the buffer and current position available when it emits
diagnostics with column information, so printing the caret is
certainly possible without much hassle. I agree that switching cpp to
use gcc's diagnostics will avoid code duplication and ensure
consistency, yet that is an orthogonal issue, it shouldn't be a
prerequisite for caret diagnostics.
Cheers,
Manuel.