On 16 May 2012 19:06, Gabriel Dos Reis <g...@integrable-solutions.net> wrote: > On Wed, May 16, 2012 at 11:56 AM, Manuel López-Ibáñez > <lopeziba...@gmail.com> wrote: >> On 16 May 2012 17:41, Jason Merrill <ja...@redhat.com> 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). Cheers, Manuel.
