Re: System header warning exemptions and delta debugging don't mix well

[caj at cs dot york dot ac dot uk]

>  > Short story:
>  > To make delta debugging more useful, gcc's STL system headers should
>  > all compile without warnings at the highest error checking level
>  > without the use of hardcoded warning suppressions in the compiler
>  > based on whether the code is in a system header or not (see
>  > http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00049.html for an example
>  > of such a suppression).
>
> How bad is it?  Can you compile all the headers with -Wsystem-headers
> and -W -Wall and see how many problems there are?
>

This isn't sufficent, as unless the templates are actually getting
instansiated then there won't be any warnings produced. Some errors are
only produced for very specific headers (for example, bitset will produce
an error about unused variables only in the case of bitset<0>, which is
valid but I'd imagine never actually used).

There appears to be a bug whereby headers in "bits/" in libstdc++ (which
is where most of the actual code is) appear uneffected by using
Wsystem-headers, so in actual fact the headers are probably already fairly
clean.

The best way to make, and keep, the headers clean would probably be to
make the libstdc++ testsuite run at a higher warning level by default. If
you do this now you'll find a lot of tests fail, but the vast majority
appear to be from problems in the headers used only in the testsuite. I'd
hoped to tackle this, but don't have enough time at the moment.

I don't imagine it would be too hard in most cases. Some warnings, for
example -Weffc++, as shown in PR14172 currently cause problems with the
libstdc++ headers, but fixing them would require pessimising or
complicating code.