================
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -std=c++20 -Wdeprecated-declarations -I%S/Inputs -verify %s
+
+#include "std-compare.h"
+
+namespace GH147293 {
+struct A {
+ [[deprecated("use something else")]] int x = 42; // expected-note {{marked
deprecated here}}
+};
+
+A makeDefaultA() { return {}; } // ctor is implicit -> no warn
+A copyA(const A &a) { return a; } // copy-ctor implicit -> no warn
+
+void assignA() {
+ A a, b;
+ a = b; // copy-assign implicit -> no warn
+}
+
+void useA() {
+ A a;
+ (void)a.x; // expected-warning {{is deprecated}}
+}
+
+// Explicitly-defaulted ctor – now silent
+struct B {
+ [[deprecated]] int y;
+ B() = default; // no warning under new policy
+};
+
+}
+
+namespace GH147293_regression {
+
+struct A {
+ [[deprecated("use something else")]] int x = 42;
+
+ auto operator<=>(const A&) const = default;
+};
+
+void foo() {
+ A x, y;
+ // FIXME: We want the deprecation warnings because operator<=> uses A.x!
+ (void)(x == y);
+}
+
+}
----------------
zyn0217 wrote:
But it also comes to a philosophy question: if users decided to mark any field
deprecated, should we compiler also respect that instruction, or do we have
some privilege to ignore anything what we consider unimportant?
I remembered we have similar issues when synthesizing CTAD guides, where the
template parameter list doesn't always conform to the standard...
(I might consider too far in this respect)
https://github.com/llvm/llvm-project/pull/219177
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
