bool f(int a, unsigned b) {
return a != b;
}
$ out/gn/bin/clang -c test.cc -Werror
test.cc:4:12: warning: comparison of integers of different signs: ‘int’ and ‘unsigned int’ [-Wsign-compare]
return a != b;
~ ^ ~
1 warning generated.
I found it surprising that this is emitted as a warning, not as an error. If this is intentional, is there some other way to say “I want my compiler warnings to always be errors”?
I don’t think we should have such a flag. The explicit intent of ‘#pragma gcc diagnostic warning’ is to allow downgrading an error to a warning, while still allowing it to be emitted.
Perhaps a new value for pragma diagnostic which emits an upgradeable warning would be reasonable.
I don’t think we should have such a flag. The explicit intent of ‘#pragma gcc diagnostic warning’ is to allow downgrading an error to a warning, while still allowing it to be emitted.
Perhaps a new value for pragma diagnostic which emits an upgradeable warning would be reasonable.
The use case here is that we don’t allow non-error diagnostics in chrome. Some subproject used #pragma GCC diagnostic warning because they wanted to configure warning flags in cc files instead of in build files for some reason. They didn’t expect this to trigger a warning instead of an error. A new pragma would meet that use case, but I don’t want source code to be able to opt out of -Werror. In my experience, once it’s known that such an option exist, someone will use it. So we do need some kind of “all warnings are errors” toggle.
Perhaps a lint rule triggering on “#pragma GCC diagnostic warning”, saying “We don’t allow warnings, please use #pragma GCC diagnostic error (or ignored)” would solve the problem sufficiently.
Separately, I note that “#pragma GCC diagnostic error” allows errors to bypass -Wfatal-errors. That certainly seems to serve no useful purpose and could be removed.
Not to be super snarky, but is there some reason why Chrome project preferences must be encoded into Clang compiler features?
This is really a stylistic choice in how you want to manage your project. There’s no end to the potential who-wins argument, whether it should be ‘#pragma dammit’ or the ‘—dammit’ command line option. We have one way in place, and you have other tactics available to enforce a different choice.
Not to be super snarky, but is there some reason why Chrome project preferences must be encoded into Clang compiler features?
It’s more “encoded in build files instead of in source code”. We pull in source code from ~100 third-party repos. We have custom build files for all of them, but don’t control the code in there.
This is really a stylistic choice in how you want to manage your project.
In general, clang is pretty flexible in how it can be used, so that it matches use cases of different projects. For example, you can enable warnings via flags or pragmas, or there’s blanket -Werror vs -Werror=each_individual_flag, etc etc etc. There isn’t really a need to offer more than one option, but different options are convenient for different projects.
How about joining stdout and stderr of the compiler, tee-ing the
output to a file too and then checking if there was any output... or
grepping for "[-W" or something. Then you could kill the build (or
send a mail or just signal or something) if a warning is emitted if
you need that specific behaviour for your build.
PATH is very powerful.
James Y Knight via cfe-dev <cfe-dev@lists.llvm.org> ezt írta (időpont:
2019. jan. 24., Cs, 18:00):