On Wed, Nov 2, 2016 at 11:51 AM, Marek Polacek <pola...@redhat.com> wrote:
> One of the pending issues that we should address before we release GCC 7 is
> that sometimes we don't issue a warning if the location points to a macro
> defined in a system header, unless -Wsystem-headers. Consider e.g.
>
> enum { e1 = LLONG_MIN };
>
> or
>
> float_var = LLONG_MIN;
>
> Here, LLONG_MIN comes from a system header and so the compiler doesn't print
> any warnings even though it should--the problem is not in the macro itself,
> but in how it's used. This has happened before, e.g. with NULL, and the fix
> was to call expansion_point_location_if_in_system_header, but this strategy
> is not tenable; there are too many such issues. After having spent days on
> this it seems that we should always use the expansion location except for
> certain pedwarns/warnings--the challenge is of course how to distinguish
> which ones. This patch introduces expand_macros_sentinel that can be used
> to suppress expanding macros, removes various
> expansion_point_location_if_in_system_header calls and fixes testsuite
> fallout. I have *not* gone over all the warnings/pedwarns yet, because this
> is touch-and-go whether this'll be considered a reasonable approach.
>
> The general principle should be: is it the macro or its user that is
> responsible for the warning?, but in practice it was often less clear to
> me what to do. So e.g. imagine
>
> #define C :
> #define F i ?: 3
>
> in a system header and then
>
> i = i ? C 5; // 1
> return F; // 2
>
> in user code -- I believe we should NOT warn for 2 (so don't expand the
> location),
> but that also means we won't warn for 1.
>
> Thoughts?
It seems to me that the general principle is that we should consider
the location where the thing we're warning about is happening. In
float_var = LLONG_MIN;
The relevant location is that of the assignment, not the constant on
the RHS. In your ?: example, a simple answer would be to warn based
on the location of the ?. The ?C example seems not worth worrying
about either way.
Jason
