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. In any case, the general rule should be that input_location (or variants using that) should be only used in the parser (who actually knows what input_location is pointing at). Other functions should use a location coming from somewhere else (an argument or a tree). UNKNOWN_LOCATION should be used for anything that is artificial/compiler-generated. Of course, in some cases, we don't have a good location at the point that we want to set one (because we get unknown_location or the tree doesn't have a location), and getting the right location there may be more work that you want to do at the moment. So I would suggest that you simply look at what the underlying function does by default (most use input_location) and use that with a FIXME (or use the non-loc variant if you don't need to touch that function call). Cheers, Manuel.
