The -Wall flag in g++ includes the flag -Wc++0x-compat, which checks for all sorts of problems that may (will) appear if the code is compiled against the new c++11 standard. But I'd like to disable that warning so that current warnings are not lost in the barrage of compatibility warnings. I haven't found anything useful in the man page, nor with Google. There doesn't seem to be a disabling flag like there is for e.g. -Wunused-variable.
Any ideas?
-Wno-c++0x-compat
Related
clang, but NOT gcc, has a -Weverything option which appears to include things such as -Wpedantic. You can test it here: https://godbolt.org/z/qcYKd1. See the top-right of the window for where I have typed in -Weverything as an explicit compiler option.
Notice the -Wvla-extension warning we get since we are relying on a C99 extension in C++ in this case, and we have -Weverything set. We get the same warning if we just use -Wpedantic, as shown here: https://godbolt.org/z/M9ahE4, indicating that -Weverything does in fact include -Wpedantic.
We get no warning if we have neither of those flags set: https://godbolt.org/z/j8sfsY.
Despite -Weverything existing and working in clang, however, I can find no documentation whatsoever on its existence, neither in the clang man pages nor in the online manual here: https://clang.llvm.org/docs/DiagnosticsReference.html. Maybe I'm looking in the wrong place? I'm not super familiar with clang's manual.
So, what does -Weverything include and where is it documented?
It seems logical to do something like -Wall -Werror -Weverything, but I don't know how that differs from just -Wall -Werror.
Dope! I just found it.
The bottom of the main clang documentation index page: https://clang.llvm.org/docs/index.html, under the "Indices and tables" section at the very bottom, has a "Search Page" link. Using that link, here is my search for "-Weverything": https://clang.llvm.org/docs/search.html?q=-Weverything, which brings me to the official documentation here!: https://clang.llvm.org/docs/UsersManual.html?highlight=weverything#cmdoption-weverything. Done! There it is!
See also: https://clang.llvm.org/docs/UsersManual.html?highlight=weverything#diagnostics-enable-everything
And the parts I really care about (emphasis added):
Since -Weverything enables every diagnostic, we generally don’t recommend using it. -Wall -Wextra are a better choice for most projects. Using -Weverything means that updating your compiler is more difficult because you’re exposed to experimental diagnostics which might be of lower quality than the default ones. If you do use -Weverything then we advise that you address all new compiler diagnostics as they get added to Clang, either by fixing everything they find or explicitly disabling that diagnostic with its corresponding Wno- option.
So, my final recommendation is to use -Wall -Wextra for warnings, but NOT -Weverything, and personally, not -Wpedantic (or -pedantic--same thing) either since I frequently rely on gcc compiler extensions for low-level embedded work and hardware-centric programming, especially on microcontrollers.
I also strongly recommend forcing all warnings into errors with -Werror. This is particularly important for safety-critical code and/or embedded firmware that needs to run forever, because it forces you to fix all warnings to get the code to fully compile. So, my final recommendation is this, as I describe further in my github repo below:
# Apply "all" and "extra" warnings, and convert them all to errors
# to force you to actually abide by them!
-Wall -Wextra -Werror
You can read my more-thorough opinion and research on this topic in my GitHub repo here: https://github.com/ElectricRCAircraftGuy/eRCaGuy_hello_world#build-notes.
Extra notes: -Wpedantic == -pedantic:
In gcc, they are the same:
Both are listed together.
-Wpedantic
-pedantic
Issue all the warnings demanded by strict ISO C and ISO C++...
In clang, they appear to be the same too, in testing and documentation. Clang also strives to be gcc-compatible in their syntax and usage: "End-User Features:"..."GCC compatibility".
-pedantic
-Wpedantic
Related:
Why should I always enable compiler warnings?
I usually run my code with ifort, but during implementation, I prefer compiling and testing with gfortran as I find it to be a lot stricter than its intel counterpart.
While turning on compiling options such as -Wall, I get the following warning:
Warning: Nonconforming tab character at (1)
Is there a way to silence this one particular warning while using the same compiling options? Note that I do NOT want to replace tabs with space characters. If there is no way to resolve this issue, then the answer "No it's not possible" would suffice.
Warning: the below answer I originally wrote only applies to gfortran 4.x. The behaviour has been reversed in version 5.x, see the answer by DrOli.
What have you tried so far? Does -Wtabs help? From man gfortran:
-Wtabs
By default, tabs are accepted as whitespace, but tabs are not members of the Fortran Character Set. For continuation lines, a tab followed by a digit between 1 and 9 is supported. -Wno-tabs
will cause a warning to be issued if a tab is encountered. Note, -Wno-tabs is active for -pedantic, -std=f95, -std=f2003, -std=f2008 and -Wall.
And -Wall sets -Wno-tabs.
If it doesn't help, it could still be that -Wall overwrites this option. Then you can try manually setting -Wall without the tabs part:
-Wall
Enables commonly used warning options pertaining to usage that we recommend avoiding and that we believe are easy to avoid. This currently includes -Waliasing, -Wampersand, -Wconversion,
-Wsurprising, -Wc-binding-type, -Wintrinsics-std, -Wno-tabs, -Wintrinsic-shadow, -Wline-truncation, -Wtarget-lifetime, -Wreal-q-constant and -Wunused.
UPDATE: With GCC/gFortran 5xx (I noticed with 5.3.0), the -Wtabs usage has been "reversed", and as they say, "made more sensible".
See here (https://gcc.gnu.org/gcc-5/changes.html)
Now -Wtabs DOES give the nonconforming warning, whereas -Wno-tabs TURNS OFF the warning (i.e. the opposite of the previous usage).
The easiest way of getting rid of the warning in gfortran versions 4.x is to overwrite the -Wno-tabs flag that the -Wall flag sets. So first include -Wall and then -Wtabs
-Wall -Wtabs
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.)
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
]>;
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
An example: I'm using -Wall -Werror and -Werror. This means unused static functions break the build. Clearly (?) unused functions are Bad, but if I'm working on code and it's in an intermediate state, want to be able to leave unused code in there. I can turn off the error with -Wno-unused-function, but then there's a risk that I'll finish what I'm working on, commit the code, and forget to remove the now-unused function.
How can I set all warnings to errors with -Wall, but downgrade specific errors to warnings, without disabling them completely?
Use the -Wno-error= flags. In the example, the required flag would be -Wno-error=unused-function.
PS: There are also pragmas for this purpose: http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html (my original question was "How can I do what these pragmas do, but in the command-line flags?" but I worked it out as I was asking it).
Is it possible to 'tell' compiler that if total number of warnings (while compiling a C++ program) are more than say 10 then stop compiling further, and emit an error?
Or is it possible to hack a compiler like clang to provide this functionality.
GCC has two options together would achieve this, from gnu online docs:
-Werror
Make all warnings into errors.
-fmax-errors=n
Limits the maximum number of error messages to n, at which point GCC bails out rather than attempting to continue processing the source
code.
This would make a build with any warnings fail though, the options just define when to stop parsing.
I haven't seen this kind of feature in gcc or clang. You can certainly try to patch it into either of them, both are open source. There is also -Werror (accepted by both compilers) which simply treats warnings as errors.
How about using -Werror to make warnings into errors and -fmax-errors=n to set the limit.
(Also, perhaps making your code completely warning free would be a good thing).