public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "j.badwaik@fz-juelich.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/106572] New: A programmatic list of all possible compiler warnings
Date: Tue, 09 Aug 2022 14:40:24 +0000	[thread overview]
Message-ID: <bug-106572-4@http.gcc.gnu.org/bugzilla/> (raw)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572

            Bug ID: 106572
           Summary: A programmatic list of all possible compiler warnings
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: j.badwaik@fz-juelich.de
  Target Milestone: ---

It would be an excellent workflow to run your code with `-Weverything` once in
a while just to check which new warnings are triggered by your code. Then,
depending on whether they are useful or not, one can incorporate those warnings
in their normal workflow. 

The alternative is to go through the release notes of every GCC release
everytime and then try to see if there is a warning which interests you. While
this is doable, it requires manual effort, with a possibility that you find no
warning which is useful. Also, depending on the code, it might not be possible
to play with all compiler warnings as soon as the compiler is released, since
you might want to wait for your code to be able to compile with the compiler
before you go there.
All of this makes for a very clumsy workflow with a lot of manual reminders
about what needs to be done.

The `-Weverything` allows for someone to schedule say a monthly CI job which
automatically runs the build with `-Weverything -Werror`. Any new compilers
added and any new warning which affects the current code will automatically be
detected. The user can then make a decision on whether the warning makes enough
sense for them to be used in their production runs.  

Currently, the way to get a list of all warning is very cumbersome. One has to
do:
> g++ -Q --help=warnings | tail -n +2 | awk '{print $1}' | tr '\n' ' '

which blows up the command line for the compilation. 

The request would be to provide either a `-Weverything` flag like clang does or
a `g++ --list-every-warning` to list all warnings in a format which can then be
passed to the compiler.

             reply	other threads:[~2022-08-09 14:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-09 14:40 j.badwaik@fz-juelich.de [this message]
2022-08-09 14:43 ` [Bug c++/106572] " mpolacek at gcc dot gnu.org
2022-08-09 14:43 ` pinskia at gcc dot gnu.org
2022-08-09 14:51 ` j.badwaik@fz-juelich.de
2022-08-09 14:53 ` j.badwaik@fz-juelich.de
2022-08-09 15:10 ` pinskia at gcc dot gnu.org
2022-08-09 15:14 ` pinskia at gcc dot gnu.org
2022-08-10  7:02 ` rguenth at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-106572-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).