28

I've found Clang's documentation to be quite poor. I haven't been able to find much of a list of available Clang warning flags. I'm interested particularly in C/C++ warnings, but this is a bit of a general issue.

GCC lists and describes warnings here, and also lists what is included in -Wall and -Wextra: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options

What warning flags are included with Clang's -Wall and -Wextra?

I can scour the Clang release notes for each version to see what new warning flags are introduced each time (e.g. http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html), but is there an easier list and/or description of Clang's warnings? This would be extremely useful. I need to know what is included in -Wall and what is not, so I can consider turning on those that are not.

(I know that -Weverything exists for Clang - might I have to resort to using that and just explicitly disabling the ones I don't like? More documentation would make this much more ideal.)

Jetski S-type
  • 1,138
  • 2
  • 16
  • 32
  • It turns out to be not very useful relying on Clang's release notes either for specifics - from http://llvm.org/releases/3.0/docs/ClangReleaseNotes.html: "Many new warnings have been added to catch common, bug-prone code patterns." – Jetski S-type Jul 23 '14 at 07:28
  • 2
    There's some interesting discussion [here](http://programmers.stackexchange.com/a/124574/102229), though it's a bit old. – T.C. Jul 23 '14 at 07:37
  • Thanks - that's interesting, though a couple years old, which is a lot in Clang development time. Some warning flags are accepted for GCC compatibility, but not implemented (though I find it interesting that a number of GCC flags are not accepted!). A couple of interesting quotes: "Conversely, I would encourage everyone to not enable flags beyond -Wextra." "[The warnings] should all eventually migrate into a proper large bucket flag [-Wall or -Wextra] or be removed from Clang." So that was the design goal then. GCC certainly doesn't try to lump all the useful flags into buckets like that. – Jetski S-type Jul 23 '14 at 23:26

2 Answers2

13

You can check the source code:

For example,

def : DiagGroup<"all", [Most, Parentheses, Switch]>;

// Warnings enabled by -pedantic.  This is magically filled in by TableGen.
def Pedantic : DiagGroup<"pedantic">;

// Aliases.
def : DiagGroup<"", [Extra]>;                   // -W = -Wextra

For -Wall look at the Most, Parentheses, Switch. You can find:

def Most : DiagGroup<"most", [ 
....

further down the file. Similarly, for extra:

def Extra : DiagGroup<"extra", [
    MissingFieldInitializers,
    IgnoredQualifiers,
    InitializerOverrides,
    SemiBeforeMethodBody,
    MissingMethodReturnType,
    SignCompare,
    UnusedParameter
  ]>;
perreal
  • 94,503
  • 21
  • 155
  • 181
6

Clang used to be very bad at documenting what was available. Though from release 4.0.0 on, they have fixed it. For older releases one can try or consult the source code. At the compiler-warnings page on Github you can find an extract of the warnings based upon the source code.

So you can find the documentation over the latest flags at the documentation pages, as well as the matching documentation for a specific release at their release pages (4.0.0).

Clang-cl has its own warning flags, of which the mapping can be found on its documentation

JVApen
  • 11,008
  • 5
  • 31
  • 67
  • The Barro version of compiler-warnings is outdated, so this fork has been actively maintained. https://github.com/pkolbus/compiler-warnings – Jetski S-type Jul 05 '23 at 11:43