Re: Feature request: -Wno-unknown-warnings to silently ignore unknown warning control flags.

[Martin Sebor <msebor at gmail dot com>]

On 10/12/2017 02:46 AM, Oren Ben-Kiki wrote:
> Motivation/Use case:
>
> * Since gcc/g++ intentionally does not have `-Weverything`, there is a
> number of explicit `-W...` flags one might wish to specify explicitly. Fair
> enough.
>
> * Additional `-W...` flags are introduced in new gcc/g++ versions, which
> check for new potential code smells, possibly related to later language
> standards. That's great (thanks!).
>
> * Not all platforms run the latest gcc/g++ compiler version. So build tools
> need to deal with a range of versions.
>
> Taking these three points together, we have a problem. The build tool
> wishes to specify `-Wshiny-new-warning` but may only do so if the gcc/g++
> compiler version is above some version X.
>
> This is difficult for several reasons:
>
> * The documentation does not clearly specify the 1st compiler version that
> supports each error/warning command line flag. One has to manually
> backtrack through the release notes for all the compiler versions.
>
> In fact the documentation also doesn't make it easy to see which flags are
> covered by other flags - one has to read through the documentation, one
> flag at a time, and extract the information from the English text. Some
> form of a more structured table would have been awesome: 1st compiler
> version supporting the flag, the list of other flags such as `-Wall` that
> imply the flag, maybe a list of related flags such as `-f...`. But that
> aside...
>
> * Even if we know which compiler version to check for, this quickly becomes
> a PITA to maintain in the build tool, given the large number of compiler
> versions in use in the wild. Having many versions means the compiler has
> been actively progressing at a fast rate, which is great! But it makes it
> nasty to deal with providing the correct warning flags for the correct
> compiler version.
>
> This is (mostly) solved with the new proposed flag: the build tool would
> simply list all the desired warning flags, which would be silently ignored
> by older compiler versions.
>
> Typos are a potential issue. One would have to run a "recent" version
> without the `-Wno-unknown-warnings` to catch such typos; that would be
> rare, and is simple enough to do (and automate in the build tool if
> desired).
>
> Another obvious issue is that the new `-Wno-unknown-warnings` flag would
> only be available starting in a future compiler version. So build tools
> would have to deal with the problem for a long time before the flag would
> provide its full benefits. Barring having a working time machine ;-)
>
> However, it is much simpler for a build tool to do a single test of whether
> or not the compiler version supports the proposed new flag, than to deal
> with the full problem of multiple versions. If the new flag is not
> supported, the build tool could fall back to using a conservative set of
> warning flags.
>
> Also, as time goes by, older compiler versions would eventually be phased
> out, so even this test would be (eventually) removed. Sure, it would take a
> decade or more, but: as the saying goes, "The best time to plant a tree is
> 20 years ago; the second best time is today".

I feel your pain.  In my last job I spent a great deal of time
dealing with the problem while supporting multiple versions of
GCC and compatible compilers (ICC and Clang at the time).
The problem was compounded by the fact that the three compilers,
while impressive in their source compatibility (down to options
specifying the exact version of the GCC dialect to be compatible
with in the case of ICC), didn't support all the same options.
My organization was particularly focused on warnings so I'm quite
familiar with the challenges you're hoping to overcome.  My
best advice is to either write a script to determine the options
the target compiler supports and use only those, or write
a compiler driver that handles this for you (it doesn't relieve
you of the tedious task of researching all the options and hard
wiring them into the driver(*)).  We ended up with the latter
approach, partly because our build system didn't have
the flexibility of configuring the build environment for
different compilers, and partly also because it allowed us
considerable flexibility (like unintrusively adjusting the
command line in various interesting and useful ways).

This isn't to say that GCC shouldn't make it easier, but as
you note, even if and when it does, it will take years before
the solution is universally available.

Martin

[*] We wrote a script scrape those off the online HTML manual
and create a "database" mapping options to GCC versions they
were introduced in (or first documented in, as not every option
always gets documented as it gets added).