[llvm-dev] [cfe-dev] Does `#pragma GCC diagnostic warning` intentionally win over -Werror?

via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 24 09:06:21 PST 2019


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.
--paulr

From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of James Y Knight via cfe-dev
Sent: Thursday, January 24, 2019 12:00 PM
To: Nico Weber
Cc: cfe-dev
Subject: Re: [cfe-dev] Does `#pragma GCC diagnostic warning` intentionally win over -Werror?

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.

On Thu, Jan 24, 2019 at 11:20 AM Nico Weber <thakis at chromium.org<mailto:thakis at chromium.org>> wrote:
On Thu, Jan 24, 2019 at 11:12 AM James Y Knight <jyknight at google.com<mailto:jyknight at google.com>> wrote:
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.


On Thu, Jan 24, 2019 at 9:56 AM Nico Weber via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
Re "intentional?", it matches gcc which explicitly documents on https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html that the pragma wins over -Werror.

Does anyone know if there's a flag that says "I want all warnings to be errors, not just most of them"?

If there isn't one yet, what would be a good UI for that?

On Wed, Jan 23, 2019 at 11:11 PM Nico Weber <thakis at chromium.org<mailto:thakis at chromium.org>> wrote:
Consider:

$ cat test.cc
#pragma GCC diagnostic warning "-Wsign-compare"

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"?

Thanks,
Nico
_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190124/22db4bba/attachment-0001.html>


More information about the llvm-dev mailing list