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

[Nico Weber via llvm-dev]

On Thu, Jan 24, 2019 at 12:06 PM <paul.robinson at sony.com> wrote:

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


>   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> wrote:
>
> On Thu, Jan 24, 2019 at 11:12 AM James Y Knight <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> 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> 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
> 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/c49ed4e6/attachment.html>