[RFC] __extension__ and warnings

[RFC] __extension__ and warnings

[Neil Booth]

I've been looking into PR 7263 about __extension__ not turning off
warnings about LL and ULL.

Not surprisingly, our treatment of warn_long_long is quite inconsistent
within front ends, and with cpplib, and with use of __extension__.

Getting things 100% right with __extension__ is hard, and would uglify
the parsers further.  I don't think the pain is worth the gain, and I
don't want to go there.  At present we turn of pedantic, warn_traditional,
warn_pointer_arith and flag_iso in the C front end, and pedantic in the
C++ front end.

I propose a simpler solution: simply do not emit any pedwarns whilst inside
the code affected by __extension__.  This is easy to implement inside
pedwarn() itself.

With this, I can clear up some confused and confusing warning logic, and fix
its interaction with cpplib's number interpreter.  Thoughts?

Neil.

Re: [RFC] __extension__ and warnings

[Gabriel Dos Reis]

Neil Booth <neil@daikokuya.co.uk> writes:

[...]

| I propose a simpler solution: simply do not emit any pedwarns whilst inside
| the code affected by __extension__.  This is easy to implement inside
| pedwarn() itself.
| 
| With this, I can clear up some confused and confusing warning logic, and fix
| its interaction with cpplib's number interpreter.  Thoughts?

At first sight, I would say that sounds reasonable.  I reserve my
comments for the concrete patch.

-- Gaby

Re: [RFC] __extension__ and warnings

[Mark Mitchell]

--On Wednesday, December 11, 2002 11:10:40 PM +0100 Gabriel Dos Reis 
<gdr@integrable-solutions.net> wrote:

> Neil Booth <neil@daikokuya.co.uk> writes:
>
> [...]
>
> | I propose a simpler solution: simply do not emit any pedwarns whilst
> inside | the code affected by __extension__.  This is easy to implement
> inside | pedwarn() itself.
> |
> | With this, I can clear up some confused and confusing warning logic,
> and fix | its interaction with cpplib's number interpreter.  Thoughts?
>
> At first sight, I would say that sounds reasonable.  I reserve my
> comments for the concrete patch.

It sounds plausible to me as well.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: [RFC] __extension__ and warnings

[Zack Weinberg]

Neil Booth <neil@daikokuya.co.uk> writes:

> Getting things 100% right with __extension__ is hard, and would uglify
> the parsers further.  I don't think the pain is worth the gain, and I
> don't want to go there.  At present we turn of pedantic, warn_traditional,
> warn_pointer_arith and flag_iso in the C front end, and pedantic in the
> C++ front end.
>
> I propose a simpler solution: simply do not emit any pedwarns whilst inside
> the code affected by __extension__.  This is easy to implement inside
> pedwarn() itself.
>
> With this, I can clear up some confused and confusing warning logic, and fix
> its interaction with cpplib's number interpreter.  Thoughts?

I'm definitely in favor of cleaning this stuff up, but I have to point
out that your proposed solution would change the effect of
__extension__ quite a bit.  It is supposed to be the case that all
warnings under if (pedantic) are pedwarn() calls, but it is not the
case that all pedwarn() calls are under if (pedantic); most of the
warnings affected by warn_traditional and warn_pointer_arith are _not_
pedwarn(), nor should they be; and I don't know what-all flag_iso
does.

The spec for pedwarn and pedantic, as I understand it, which may be a
bit out of date, is:

 - If and only if the diagnostic in question is mandated by the
   relevant standard (C89, C99, C++98, F77, etc) use pedwarn()
   (unless you are using error() instead).

 - If, despite this, we do not think the warning should be on by
   default, put the pedwarn call under if (pedantic) or possibly
   if (pedantic||Wall).

The spec for __extension__ is, it asserts that the following
expression makes deliberate use of GNU extensions under proper
#ifdeffage, so don't bug the programmer about it.  Some, but not all,
GNU extensions draw mandatory diagnostics; others are properly
complained about by -Wtraditional and the like.  So the two properties
are somewhat orthogonal.

I'm now imagining turning the DT_* enumeration into a set of bitflags,
so that you could write e.g.

  diagnostic (DT_EXTENSION | DT_MANDATED | DT_WARNING, "...")

to achieve the effect of 'pedwarn but shut up under __extension__.'

zw

Re: [RFC] __extension__ and warnings

[Neil Booth]

Zack Weinberg wrote:-

> The spec for pedwarn and pedantic, as I understand it, which may be a
> bit out of date, is:
> 
>  - If and only if the diagnostic in question is mandated by the
>    relevant standard (C89, C99, C++98, F77, etc) use pedwarn()
>    (unless you are using error() instead).
> 
>  - If, despite this, we do not think the warning should be on by
>    default, put the pedwarn call under if (pedantic) or possibly
>    if (pedantic||Wall).
> 
> The spec for __extension__ is, it asserts that the following
> expression makes deliberate use of GNU extensions under proper
> #ifdeffage, so don't bug the programmer about it.  Some, but not all,
> GNU extensions draw mandatory diagnostics; others are properly
> complained about by -Wtraditional and the like.  So the two properties
> are somewhat orthogonal.
> 
> I'm now imagining turning the DT_* enumeration into a set of bitflags,
> so that you could write e.g.
> 
>   diagnostic (DT_EXTENSION | DT_MANDATED | DT_WARNING, "...")
> 
> to achieve the effect of 'pedwarn but shut up under __extension__.'

I prefer this.  Fancy changing all error(), warning(), pedwarn(), ...,
calls?  8-)

Neil.

Re: [RFC] __extension__ and warnings

[Neil Booth]

Neil Booth wrote:-

> > I'm now imagining turning the DT_* enumeration into a set of bitflags,
> > so that you could write e.g.
> > 
> >   diagnostic (DT_EXTENSION | DT_MANDATED | DT_WARNING, "...")
> > 
> > to achieve the effect of 'pedwarn but shut up under __extension__.'

I think you mean DL_ constants, like I'm using in cpplib?  It was meant
to stand for diagnostic level.

> I prefer this.  Fancy changing all error(), warning(), pedwarn(), ...,
> calls?  8-)

Roughly there are 1965 error(), 820 warning() and 330 pedwarn() calls;
this includes the _with variants.  Piece of cake 8-)

This is probably a good 3.4 project; it would be a great cleanup of our
diagnostics system.  Do you agree Gaby?

Neil.

Re: [RFC] __extension__ and warnings

[Gabriel Dos Reis]

Neil Booth <neil@daikokuya.co.uk> writes:

| Neil Booth wrote:-
| 
| > > I'm now imagining turning the DT_* enumeration into a set of bitflags,
| > > so that you could write e.g.
| > > 
| > >   diagnostic (DT_EXTENSION | DT_MANDATED | DT_WARNING, "...")
| > > 
| > > to achieve the effect of 'pedwarn but shut up under __extension__.'
| 
| I think you mean DL_ constants, like I'm using in cpplib?  It was meant
| to stand for diagnostic level.
| 
| > I prefer this.  Fancy changing all error(), warning(), pedwarn(), ...,
| > calls?  8-)
| 
| Roughly there are 1965 error(), 820 warning() and 330 pedwarn() calls;
| this includes the _with variants.  Piece of cake 8-)
| 
| This is probably a good 3.4 project; it would be a great cleanup of our
| diagnostics system.  Do you agree Gaby?

Yes, definitely.

-- Gaby