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

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>

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>