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:

>> I tend to favor this, provided that the performance is not too awful.
>> But maybe this is painful due to iconv translation?

Manuel> How should a file be properly opened within GCC? I find the
Manuel> code in libcpp/files.c pretty confusing and also I am not
Manuel> interested in parsing the file, so some of the conversions it
Manuel> makes are probably superflous (or perhaps even impossible when
Manuel> calling from expand_location).

Yeah, it is pretty confusing.

I think we should bypass most of the libcpp machinery in the reopen
case.  A lot of that code is for searching the include path, and stuff
like that -- but once we have read the file, we know exactly where it

So, I would say, just reopen it like you would any file.

I think you will still need to dig through the charset translation
stuff a bit and handle that.  Otherwise you may end up printing

>> How about -fshow-caret instead of -fdiagnostics-show-caret?
>> (By analogy with -fshow-column.)

Manuel> Well, we have -fdiagnostics-show-option and
Manuel> -fdiagnostics-show-location. So 2 versus 1. ;-) That said, I would
Manuel> also prefer -fshow-option and -fshow-location.

Yeah.  "diagnostics" is too long to type, and "ambiguously plural", if
you know what I mean.

Manuel> I agree that switching cpp to use gcc's diagnostics will avoid
Manuel> code duplication and ensure consistency, yet that is an
Manuel> orthogonal issue, it shouldn't be a prerequisite for caret
Manuel> diagnostics.

Yes, I agree.


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