On 8/30/24 1:34 PM, Jakub Jelinek wrote:
On Mon, Aug 19, 2024 at 05:05:51PM -0400, Jason Merrill wrote:
I've tried to compile it also with latest clang and there is agreement in
most of the diagnostics, just at block scope (inside of foo) it doesn't
diagnose
auto e = new int [n] [[deprecated]];
auto e2 = new int [n] [[deprecated]] [42];
[[deprecated]] lab:;
and at namespace scope
[[deprecated]];
I think that all feels like clang++ bug.
On the other side, clang++ diagnoses
enum B { B0 } [[deprecated]];
but GCC with all the patches I've posted today doesn't, is that a GCC bug?
I think so, yes.
Fixed in the just posted 2 patches.
The FIXMEs are where there is agreement with clang++, but I'm not sure.
One thing is I'm not sure if "a variable" above is meant to include function
parameters, and/or unused function parameters without a specified name,
function parameters inside of a function declaration rather than definition
and/or static data members.
All of those, I believe.
Removed the FIXMEs.
Also unsure about
[[deprecated]] int : 0;
at class scope, that isn't a non-static data member...
Indeed, pedantically the standard says it can't apply to an unnamed
bit-field.
And the following updated version on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661904.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661905.html
patches also diagnoses the attribute on unnamed bit-fields.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-08-30 Jakub Jelinek <ja...@redhat.com>
PR c++/110345
* parser.cc (cp_parser_std_attribute): Don't transform
[[deprecated]] into [[gnu::deprecated]].
* tree.cc (handle_std_deprecated_attribute): New function.
(std_attributes): Add deprecated entry.
* g++.dg/cpp0x/attr-deprecated1.C: New test.
--- gcc/cp/parser.cc.jj 2024-08-30 11:13:18.612089567 +0200
+++ gcc/cp/parser.cc 2024-08-30 12:55:17.875362909 +0200
@@ -30357,12 +30357,11 @@ cp_parser_std_attribute (cp_parser *pars
/* We used to treat C++11 noreturn attribute as equivalent to GNU's,
but no longer: we have to be able to tell [[noreturn]] and
- __attribute__((noreturn)) apart. */
- /* C++14 deprecated attribute is equivalent to GNU's. */
- if (is_attribute_p ("deprecated", attr_id))
- TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
+ __attribute__((noreturn)) apart.
+ Similarly for C++14 deprecated attribute, we need to emit extra
+ diagnostics for [[deprecated]] compared to [[gnu::deprecated]]. */
/* C++17 fallthrough attribute is equivalent to GNU's. */
- else if (is_attribute_p ("fallthrough", attr_id))
+ if (is_attribute_p ("fallthrough", attr_id))
TREE_PURPOSE (TREE_PURPOSE (attribute)) = gnu_identifier;
/* C++23 assume attribute is equivalent to GNU's. */
else if (is_attribute_p ("assume", attr_id))
--- gcc/cp/tree.cc.jj 2024-08-15 22:23:07.908239976 +0200
+++ gcc/cp/tree.cc 2024-08-30 13:15:26.863829810 +0200
@@ -5087,6 +5087,25 @@ handle_likeliness_attribute (tree *node,
return error_mark_node;
}
+/* The C++14 [[deprecated]] attribute mostly maps to the GNU deprecated
+ attribute. */
+
+static tree
+handle_std_deprecated_attribute (tree *node, tree name, tree args, int flags,
+ bool *no_add_attrs)
+{
+ tree t = *node;
+ tree ret = handle_deprecated_attribute (node, name, args, flags,
+ no_add_attrs);
+ if (TYPE_P (*node) && t != *node)
+ pedwarn (input_location, OPT_Wattributes,
+ "%qE on a type other than class or enumeration definition", name);
+ else if (TREE_CODE (*node) == FIELD_DECL && DECL_UNNAMED_BIT_FIELD (*node))
+ pedwarn (input_location, OPT_Wattributes, "%qE on unnamed bit-field",
+ name);
Why not warn about these for the GNU deprecated attribute as well?
Jason