3

I wonder if there's some clever, automatic way of knowing if a particular compiler warning (e.g. -Wunused-parameter) comes from the group -Wall, -Wextra, or another group, for both GCC and Clang.

Use case: we want to enable:

-Wall -Wextra -pedantic

However, some of the pedantic warnings are unapplicable to us and we want to disable them, example:

-Wall -Wextra -pedantic -Wno-c++20-designator

Now, we want to be 100% sure that we are not disabling anything from -Wall nor -Wextra. How do we ensure that -Wc++20-designator is not part of either? Of course one can go and check the documentation, but this is a tedious process when you have many such warnings or when you upgrade the compiler and get new warnings.

Our use case to ensure that all -Wall, -Wextra warnings will always be active, regardless of the disabled warnings from -pedantic.

Thanks!

user1011113
  • 1,114
  • 8
  • 27
  • Please one question per question. `Automatically know if a GCC/Clang warning comes from Wall or Wextra?` is not an alternative to `is there a way to ensure that all -Wall, -Wextra warnings will always be active, regardless of the disabled warnings?`. I also do not understand the second question, yes, there is a way, do not disable any warnings. – KamilCuk Nov 30 '21 at 12:44
  • "we want to be 100% sure that we are not disabling anything from -Wall nor -Wextra". That sounds like a management feature and I am wondering why `pedantic` is not the minimum. Which warning is enabled in which state is listed in the gcc docs. But I believe it will change from time to time and maybe the doc will not change always. I personally like to see every warning and fix as soon as possible. Which warning is switched on by the flags can be seen here: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html. We compile our unit test targets with ALL warnings and count them. >0 is fault! – Klaus Nov 30 '21 at 12:45
  • @KamilCuk that's not an answer to the question. Klaus "which one is the minimum" is out of this discussion. I'm aware of the GCC link, even though there's not an equivalent one for Clang (you need to do more detective work). I'll update the question in this regard. My question is if this can be done automatically/programatically instead of manually going into the docs every time. – user1011113 Nov 30 '21 at 12:54
  • Updated question to be formulated as only 1 question. – user1011113 Nov 30 '21 at 12:56
  • 3
    You can ask gcc what is enabled by which option, try `gcc -Q -Wall --help=warnings | grep enabled`. Would that help you? –  Nov 30 '21 at 13:02
  • @dratenik That's great, thanks a lot! I can definitely use that. With a bit of scripting and diffing I can arrive to the answer I'm looking for. Do you know if a similar thing is available in Clang? – user1011113 Nov 30 '21 at 13:09
  • Not easily. [Someone suggests](https://stackoverflow.com/a/24904618/14215102) grabbing the appropriate source code and parsing that. –  Nov 30 '21 at 13:16

1 Answers1

1

There's no specific command to get a direct answer to the question "which warning group does a given warning come from?", but it's possible to infer this information automatically by querying the compiler which warnings are enabled and checking if the warning we are interested in is part of the list of enabled warnings.

This is done as follows:

  • GCC: gcc -Q -Wall --help=warnings | grep enabled | grep unused-parameter (credits to @dratenik).
  • Clang: this functionality is not baked into the compiler, unlike GCC, so we need to use the diagtool tool: diagtool show-enabled -Wall foo.cpp | grep unused-parameter.

Bonus: Unrelated to the original question but related to the original use case: to be sure that all of Wall and Wextra are enabled, regardless of which warnings are disabled, the solution (only works for Clang) is to put Wall Wextra at the very end:

clang -Wno-unused-parameter -Wall -Wextra

In this case, if we accidentally disable the unused-parameter warning, Wall will be applied after, re-enabling the warning.

user1011113
  • 1,114
  • 8
  • 27