>maybe_warning (OPT_Wfoo, frobbed, "foo is frobbed");
>
> This tests whether Wfoo is enabled *before* it evaluates frobbed.
In the cases where such a check is warranted, "frobbed" is usually a
fairly large collection of tests. It would be impractical (and ugly)
to put such logic inside a ma
Giovanni Bajo wrote:
Actually, the point is that you *never* need to explicitally name the
"warn_" variable unless you are optimizing. In other words, code which
presently is:
if (warn_foo
&& frobbed)
warning (0, "foo is frobbed");
should be replaced with:
if (frobbed)
warning (OPT_W
> Is that behaviour documented somewhere I missed?
Sadly, no. Actually, none of the diagnostic calls are documented.
The prototypes are even in toplev.h instead of diagnostic.h, between
"fatal_insn_not_found() and "rest_of_decl_compilation()". It's quite
haphazard.
The diagnostic_info structur
DJ Delorie <[EMAIL PROTECTED]> writes:
| > I don't care if it's spelt warn_foo, OPT_Wfoo, warning_p(foo) or
| > whatever, so long as it's spelt only one way. The 'warning
| > (OPT_Wfoo, ...)' syntax helps only where there is no conditional
| > before the warning -- how often does that occur? The
DJ Delorie <[EMAIL PROTECTED]> writes:
| > [3] shows which options is used to enable/disable that diagnostic
| > (assumming it is controled by a particular switch). In either case
| > the main diagnostic is always emitted.
|
| No, [3] will also enable/disable the warning, as the OPT_* is used to
> I don't care if it's spelt warn_foo, OPT_Wfoo, warning_p(foo) or
> whatever, so long as it's spelt only one way. The 'warning
> (OPT_Wfoo, ...)' syntax helps only where there is no conditional
> before the warning -- how often does that occur? The way it
> currently is, one runs the risk of wr
> You need to pass the option to warning() also for another reason: we want to
> be able to optionally print which flag can be used to disable each warning,
> so warning() has to be smarter than it used to be.
In addition, we've talked about the idea of having the diagnostic
machinery keep track
Nathan Sidwell <[EMAIL PROTECTED]> wrote:
> I'm inclined to agree it is confusing. especially as in one place one has
to
> write warn_ and in the other place one writes OPT_W. It'd be
> nice if one just wrote
> if (warn_foo && frobbed)
> warning ("foo is frobbed");
>
> I don't care if i
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| DJ Delorie <[EMAIL PROTECTED]> wrote:
|
| >> So, I assume this patch is wrong in this regard:
| >> http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00392.html
| >
| > Yes, it's wrong in that way.
|
| Gaby, can you please fix it then?
Sure, see the message
Gabriel Dos Reis wrote:
As pointed out by JSM yesterday, it is not clear whether [1] should be
preferred over [2] or the converse. I think having two ways to
control the same diagnostic is a bit confusing. I think the
I'm inclined to agree it is confusing. especially as in one place one has
> [3] shows which options is used to enable/disable that diagnostic
> (assumming it is controled by a particular switch). In either case
> the main diagnostic is always emitted.
No, [3] will also enable/disable the warning, as the OPT_* is used to
look up the variable, and the variable is checke
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Hello DJ,
|
| I'm updating a piece of code of the C++ frontend which involves a warning,
| so I was planning on adding the correct warning option to it. The original
| code is the following:
|
| if (warn_missing_braces)
|warning (0,
DJ Delorie <[EMAIL PROTECTED]> wrote:
>> So, I assume this patch is wrong in this regard:
>> http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00392.html
>
> Yes, it's wrong in that way.
Gaby, can you please fix it then?
--
Giovanni Bajo
> So, I assume this patch is wrong in this regard:
> http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00392.html
Yes, it's wrong in that way.
DJ Delorie <[EMAIL PROTECTED]> wrote:
>> if (OPT_Wmissing_braces)
>>warning (OPT_Wmissing_braces, "missing braces around
>> initializer");
>
> FYI OPT_Wmissing_braces is an enum constant; it will always be nonzero.
So, I assume this patch is wrong in this regard:
http://gcc.gnu
> if (OPT_Wmissing_braces)
>warning (OPT_Wmissing_braces, "missing braces around
> initializer");
FYI OPT_Wmissing_braces is an enum constant; it will always be nonzero.
> [3]
> warning (OPT_Wmissing_braces, "missing braces around initializer");
That is what we decided t
16 matches
Mail list logo
