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: [C++ Patch] PR 44516

On 16 May 2012 19:06, Gabriel Dos Reis <> wrote:
> On Wed, May 16, 2012 at 11:56 AM, Manuel López-Ibáñez
> <> wrote:
>> On 16 May 2012 17:41, Jason Merrill <> wrote:
>>> On 05/16/2012 06:54 AM, Paolo Carlini wrote:
>>>> isn't the diagnostic machinery able to cope with UNKNOWN_LOCATION? By
>>>> default should be interpreted as input_location, no?
>>> That would make sense to me; I don't know if it works that way now, though.
>> No, I don't think it works that way. In fact, if something printed in
>> diagnostics has an unknown location, that seems a bug, because either
>> it is some artificial construct that we should not be giving
>> diagnostics about, or the location passed down is wrong. Of course,
>> for release compilers, we could add a check in
>> diagnostic_report_diagnostic() and use input_location instead. For
>> development compilers we could have a gcc_checking_assert(location !=
>> UNKNOWN_LOCATION). But I am not sure what would happen for such a
>> check.
> hmm; triggering assertions while reporting diagnostics has usually
> been unfunny because this is the diagnostics: it is called when we
> think there is something wrong with our internal data structures.
> Rather, we should handle the situations gracefully.

My proposal is to assert when checking is enabled (gcc_checking_assert
instead of gcc_assert) and degrade gracefully when not (use
input_location if given an UNKNOWN_LOCATION). The diagnostics that are
called when something goes wrong internally do not use explicit
locations (in fact, they use input_location which is often useless,
but ok that is only a problem for GCC developers, not for users).



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