On 5/26/21 3:18 PM, Martin Sebor wrote:
On 5/26/21 8:00 AM, Jason Merrill wrote:
On 5/13/21 9:07 PM, Jason Merrill wrote:
On 5/13/21 7:38 PM, Martin Sebor wrote:
On 5/13/21 1:28 PM, Jason Merrill via Gcc-patches wrote:
Ping.
On 4/28/21 9:32 AM, Jason Merrill wrote:
-Wdeprecated-copy was depending only on the state of the warning
at the
point where we call the function, making it hard to use #pragma
diagnostic
to suppress the warning for a particular implicitly declared
function.
But checking whether the warning is enabled at the location of the
implicit
declaration turned out to be a bit complicated; option_enabled
only tests
whether it was enabled at the start of compilation, the actual
test only
existed in the middle of diagnostic_report_diagnostic. So this patch
factors it out and adds a new warning_enabled function to
diagnostic.h.
There is a bit of overlap in this patch with my work here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563862.html
but nothing that concerns me, for whatever it's worth.
In my ongoing work to extend TREE_NO_WARNING to more than one bit
I've been thinking of introducing a function (actually a pair of
them) similar to warning_enabled(). The overloads will take
a tree and gimple* rather than a location so that they can consider
the inlining context. This is only useful in the middle end so
front ends can still use location_t.
Just one suggestion: since warning_at() takes location_t and int
for the option in that order, I would recommend doing the same
for warning_enabled(), just to reduce the risk of confusion.
(It would be nice if location_t could be something other than
an arithmetic type).
Sure. I'd probably rename it to warning_enabled_at, in that case,
and drop the default argument.
Looks like I never sent the (slightly) updated patch.
Still no concerns from me, just an update on the TREE_NO_WARNING
comment above. The patch I posted on Monday adds a
get_no_warning (location_t, int)
function to query the no-warning status for the location (a new
thing also introduced in the patch). Since your change will likely
go in first, I'll need to decide I should make warning_enabled_at()
conditional on get_no_warning(location_t, int). I'm thinking yes.
Yes, I would think to check it in my diagnostic_enabled, so that
diagnostic_report_diagnostic is also affected.
Also, as a followup on the TREE_NO_WARNING patch I've been thinking
of making diagnostic_report_diagnostic() conditional on the result
of get_no_warning() to avoid having to test the no-warning bitmap
in warning_at() callers. (The checking in the middle end has in
the past inadvertently introduced codegen dependencies on warnings.)
Incidentally, looking at cp_warn_deprecated_use() I wonder if that's
one such call site where the warning_enabled_at() call could already
be avoided by calling warning_at (DECL_SOURCE_LOCATION (decl), ...)
instead of warning().
No, they're two different locations; I want to check if the warning is
enabled at the function definition before warning at the call site.
Jason
