This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] GCC caret diagnostics

>>>>> "Manuel" == Manuel LÃpez-IbÃÃez <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]