Re: Update pass manager to handle generate_summary/transform functions

["Manuel López-Ibáñez" <lopezibanez at gmail dot com>]

2008/7/16 Ian Lance Taylor <iant@google.com>:
> "Rafael Espindola" <espindola@google.com> writes:
>
>>> Why is it necessary to set input_location before calling this warning?
>>> The warning uses %H anyhow.
>>
>> Because with the patch it uses input_location to find out if we are in
>> a system header or not.
>
> Ah.  That seems problematic.  I don't want changing input_location to
> be a standard approach.  If anything, that seems like a step backward.
> I would prefer to see some sort of change to the diagnostic machinery.

I think the correct approach is to make in_system_headers take a
location as argument. Then, one can test for the current
input_location or the location of a declaration. Next, you use:

 /* Returns nonzero if warnings should be emitted.  */
 #define diagnostic_report_warnings_p(LOC)			\
   (!inhibit_warnings					\
   && !(in_system_header (LOC) && !warn_system_headers))

However, this assumes that you have managed somehow to obtain the
location at the point when diagnostic_report_warnings_p is called. The
current way to get the location is a bit obscure but if you change
warning to take a explicit location_t parameter, then it is easy.
Unfortunately, changing warning() is probably not trivial itself, so I
don't know which of the two alternatives is better.

The next step would be to fix the two problems you mentioned above:

> *) In some places we use in_system_header just to avoid warnings.

These are hacks added because the current diagnostic machinery doesn't
avoid warning sometimes even if the warning refers to something
declared in system headers. That is, precisely what you are trying to
fix. If you fix the diagnostics machinery, you can probably delete
most of those.

Nonetheless, if there are some that you cannot delete (and I am sure
there would be some because there are other problems lurking here) you
could also replace them by in_system_header(input_location) or
in_system_header(DECL_SOURCE_LOCATION(t)) or whatever it is
appropriate for that line.

> *) in_system_headers and location are not kept in perfect sync. In
> particular, the function "warning" should probably take a location_t
> argument informing where the warning happened.

This should not be a problem if you can get the location from
warning(): whatever location warning uses to print, you call
in_system_header(location). In those cases where the current
in_system_header  and input_location are not in sync and the warning
uses input_location, you would need to add an explicit location to
warning().

Do you see any problem with this approach? I think this is more or
less what Tom was proposing initially.

BTW, can we change the subject of this thread? It is totally
misleading. I almost missed this discussion and I have been willing to
tackle this problem for a long time but the problems described above
stopped me and now I don't have enough free time.

Cheers,

Manuel.