[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-13 Thread Roy Jacobson via Phabricator via cfe-commits
royjacobson added a comment.

In D129170#3650618 , @glandium wrote:

> From the commit message:
>
>> This patch adds deprecation warnings for the usage of those builtins, except 
>> for __has_trivial_destructor which doesn't have a GCC alternative.
>
> The exception for __has_trivial_destructor doesn't seem to be true, FWIW.

Oh, I'm really sorry for that :/ It was changed because Aaron asked me to add 
it as well, but I forgot to update the summary.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-13 Thread Mike Hommey via Phabricator via cfe-commits
glandium added a comment.

From the commit message:

> This patch adds deprecation warnings for the usage of those builtins, except 
> for __has_trivial_destructor which doesn't have a GCC alternative.

This doesn't seem to be true, FWIW.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-12 Thread Roy Jacobson via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0b89d1d59f82: [Sema] Add deprecation warnings for some 
compiler provided __has_* type traits (authored by royjacobson).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/CXX/dcl.decl/dcl.init/p5.cpp
  clang/test/CXX/drs/dr18xx.cpp
  clang/test/CXX/drs/dr21xx.cpp
  clang/test/CXX/special/class.copy/p12-0x.cpp
  clang/test/CXX/special/class.copy/p25-0x.cpp
  clang/test/CXX/special/class.ctor/p5-0x.cpp
  clang/test/Modules/cxx-decls.cpp
  clang/test/SemaCXX/cxx0x-defaulted-functions.cpp
  clang/test/SemaCXX/cxx11-crashes.cpp
  clang/test/SemaCXX/deprecated-builtins.cpp
  clang/test/SemaCXX/sizeless-1.cpp
  clang/test/SemaCXX/trivial-constructor.cpp
  clang/test/SemaCXX/trivial-destructor.cpp
  clang/test/SemaCXX/type-traits.cpp
  clang/test/SemaObjCXX/arc-type-traits.mm
  clang/test/SemaObjCXX/objc-weak-type-traits.mm

Index: clang/test/SemaObjCXX/objc-weak-type-traits.mm
===
--- clang/test/SemaObjCXX/objc-weak-type-traits.mm
+++ clang/test/SemaObjCXX/objc-weak-type-traits.mm
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -fobjc-weak -fobjc-runtime-has-weak -verify -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -fobjc-weak -fobjc-runtime-has-weak -verify -std=c++11 %s -Wno-deprecated-builtins
 // expected-no-diagnostics
 
 // Check the results of the various type-trait query functions on
Index: clang/test/SemaObjCXX/arc-type-traits.mm
===
--- clang/test/SemaObjCXX/arc-type-traits.mm
+++ clang/test/SemaObjCXX/arc-type-traits.mm
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -fobjc-arc -fobjc-runtime-has-weak -verify -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -fobjc-arc -fobjc-runtime-has-weak -verify -std=c++11 %s -Wno-deprecated-builtins
 // expected-no-diagnostics
 
 // Check the results of the various type-trait query functions on
Index: clang/test/SemaCXX/type-traits.cpp
===
--- clang/test/SemaCXX/type-traits.cpp
+++ clang/test/SemaCXX/type-traits.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++11 -fms-extensions -Wno-microsoft %s
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++14 -fms-extensions -Wno-microsoft %s
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++1z -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++11 -Wno-deprecated-builtins -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++14 -Wno-deprecated-builtins -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++1z -Wno-deprecated-builtins -fms-extensions -Wno-microsoft %s
 
 #define T(b) (b) ? 1 : -1
 #define F(b) (b) ? -1 : 1
Index: clang/test/SemaCXX/trivial-destructor.cpp
===
--- clang/test/SemaCXX/trivial-destructor.cpp
+++ clang/test/SemaCXX/trivial-destructor.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11 -Wno-deprecated-builtins
 // expected-no-diagnostics
 struct T1 {
 };
Index: clang/test/SemaCXX/trivial-constructor.cpp
===
--- clang/test/SemaCXX/trivial-constructor.cpp
+++ clang/test/SemaCXX/trivial-constructor.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11 -Wno-deprecated-builtins
 // expected-no-diagnostics
 struct T1 {
 };
Index: clang/test/SemaCXX/sizeless-1.cpp
===
--- clang/test/SemaCXX/sizeless-1.cpp
+++ clang/test/SemaCXX/sizeless-1.cpp
@@ -1,7 +1,7 @@
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wno-unused-but-set-variable -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++98 %s
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wno-unused-but-set-variable -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++11 %s
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wno-unused-but-set-variable -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++17 %s
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall 

[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-12 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM, thank you!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-11 Thread Roy Jacobson via Phabricator via cfe-commits
royjacobson added inline comments.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5400-5401
+SourceLocation KWLoc) {
+  if (!S.getLangOpts().CPlusPlus11)
+return;
+

aaron.ballman wrote:
> royjacobson wrote:
> > aaron.ballman wrote:
> > > erichkeane wrote:
> > > > royjacobson wrote:
> > > > > erichkeane wrote:
> > > > > > royjacobson wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > I think we should always warn on these, not just in C++11.
> > > > > > > I'm not convinced we should. My reasoning is that we need a 
> > > > > > > pretty good reason to start issuing warnings for 20 years old 
> > > > > > > code. The usage of those builtins with deleted functions after 
> > > > > > > C++11 is pretty broken which is a pretty good reason, but for 
> > > > > > > earlier language versions they work 'fine' and if people want to 
> > > > > > > use C++03 I prefer leaving them at peace :)
> > > > > > > 
> > > > > > > People on C++03 are also probably using pretty old versions of 
> > > > > > > libstdc++ and/or boost type_traits, so this could have some 
> > > > > > > impact.
> > > > > > > 
> > > > > > > WDYT?
> > > > > > > 
> > > > > > warnings don't get emitted for code in header files, so at least 
> > > > > > that part isn't a concern.  
> > > > > Any header files, or just system headers?
> > > > Sorry, yes, Phab is a mess on a cell phone... in things included as 
> > > > System Headers.
> > > Agreed with Erich -- warnings in system headers (but not regular headers) 
> > > are silenced by default, you need to pass `-Wsystem-headers` to enable 
> > > them.
> > To clarify my position, I think about those builtins as an unofficial part 
> > of the C++03 standard and I think we should support them as long as we 
> > support C++03.
> > 
> > Do you think that's reasonable?
> > 
> > I agree we should update the documentation in this case.
> I still don't see the benefit of undeprecating these in C++03. The 
> replacement interfaces are available for use in C++03 mode, so there's 
> nothing that prevents a user from being pushed to use the supported 
> interfaces instead, right? To me, the older interfaces were not clean/correct 
> and the replacement interfaces are the ones that we want people to use, and 
> that's language mode agnostic.
I think they're 
1. Clean enough under C++03 semantics - without the extra complications of move 
semantics, defaulted/deleted functions etc.
2. Potentially pretty widely used in code that needs C++03, though I have no 
idea how to check that.

But you convinced me that it's probably not that of a big deal to add those 
warnings anyway, so let's add them and think about actual deprecation in a few 
years :)




Comment at: clang/lib/Sema/SemaExprCXX.cpp:5433
+// FIXME: GCC don't implement __is_trivially_destructible: Warning for this
+//   might be too noisy for now.
+// case UTT_HasTrivialDestructor:

aaron.ballman wrote:
> royjacobson wrote:
> > aaron.ballman wrote:
> > > I'd like to know how plausible that "might" is -- Clang flags it as being 
> > > deprecated, so it seems very reasonable to diagnose it as such. These 
> > > diagnostics won't be triggered from system headers by default anyway, so 
> > > I'm not certain if this will be too noisy in practice.
> > It's used in libstdc++'s type_traits and in boost's type_traits (but we 
> > will start warning on boost's type_traits anyway). So it's even if by 
> > default people are not going to see it I think it's used widely enough to 
> > be problematic and we shouldn't warn on this for now.
> > 
> > I added the libstdc++ part to the comment as well.
> My feeling is: if it's deprecated and we don't warn on it, it's not actually 
> deprecated. I'd rather see us warn uniformly on all the deprecated 
> interfaces. System headers are free to keep using these interfaces (system 
> headers are long lived), but any user code using this needs some sort of 
> notification that they're using something we don't want them to use, or we 
> will never be able to get rid of these interfaces (at which point, we should 
> undeprecate them because we need to keep them working).
Ok, added it to the warnings.



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-11 Thread Roy Jacobson via Phabricator via cfe-commits
royjacobson updated this revision to Diff 443742.
royjacobson added a comment.

Warn on <=C++03 as well, warn on __has_trivial_destructor.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/CXX/dcl.decl/dcl.init/p5.cpp
  clang/test/CXX/drs/dr18xx.cpp
  clang/test/CXX/drs/dr21xx.cpp
  clang/test/CXX/special/class.copy/p12-0x.cpp
  clang/test/CXX/special/class.copy/p25-0x.cpp
  clang/test/CXX/special/class.ctor/p5-0x.cpp
  clang/test/Modules/cxx-decls.cpp
  clang/test/SemaCXX/cxx0x-defaulted-functions.cpp
  clang/test/SemaCXX/cxx11-crashes.cpp
  clang/test/SemaCXX/deprecated-builtins.cpp
  clang/test/SemaCXX/sizeless-1.cpp
  clang/test/SemaCXX/trivial-constructor.cpp
  clang/test/SemaCXX/trivial-destructor.cpp
  clang/test/SemaCXX/type-traits.cpp
  clang/test/SemaObjCXX/arc-type-traits.mm
  clang/test/SemaObjCXX/objc-weak-type-traits.mm

Index: clang/test/SemaObjCXX/objc-weak-type-traits.mm
===
--- clang/test/SemaObjCXX/objc-weak-type-traits.mm
+++ clang/test/SemaObjCXX/objc-weak-type-traits.mm
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -fobjc-weak -fobjc-runtime-has-weak -verify -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -fobjc-weak -fobjc-runtime-has-weak -verify -std=c++11 %s -Wno-deprecated-builtins
 // expected-no-diagnostics
 
 // Check the results of the various type-trait query functions on
Index: clang/test/SemaObjCXX/arc-type-traits.mm
===
--- clang/test/SemaObjCXX/arc-type-traits.mm
+++ clang/test/SemaObjCXX/arc-type-traits.mm
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -fobjc-arc -fobjc-runtime-has-weak -verify -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -fobjc-arc -fobjc-runtime-has-weak -verify -std=c++11 %s -Wno-deprecated-builtins
 // expected-no-diagnostics
 
 // Check the results of the various type-trait query functions on
Index: clang/test/SemaCXX/type-traits.cpp
===
--- clang/test/SemaCXX/type-traits.cpp
+++ clang/test/SemaCXX/type-traits.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++11 -fms-extensions -Wno-microsoft %s
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++14 -fms-extensions -Wno-microsoft %s
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++1z -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++11 -Wno-deprecated-builtins -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++14 -Wno-deprecated-builtins -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++1z -Wno-deprecated-builtins -fms-extensions -Wno-microsoft %s
 
 #define T(b) (b) ? 1 : -1
 #define F(b) (b) ? -1 : 1
Index: clang/test/SemaCXX/trivial-destructor.cpp
===
--- clang/test/SemaCXX/trivial-destructor.cpp
+++ clang/test/SemaCXX/trivial-destructor.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11 -Wno-deprecated-builtins
 // expected-no-diagnostics
 struct T1 {
 };
Index: clang/test/SemaCXX/trivial-constructor.cpp
===
--- clang/test/SemaCXX/trivial-constructor.cpp
+++ clang/test/SemaCXX/trivial-constructor.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11 -Wno-deprecated-builtins
 // expected-no-diagnostics
 struct T1 {
 };
Index: clang/test/SemaCXX/sizeless-1.cpp
===
--- clang/test/SemaCXX/sizeless-1.cpp
+++ clang/test/SemaCXX/sizeless-1.cpp
@@ -1,7 +1,7 @@
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wno-unused-but-set-variable -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++98 %s
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wno-unused-but-set-variable -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++11 %s
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wno-unused-but-set-variable -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++17 %s
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wno-unused-but-set-variable -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=gnu++17 %s
+// RUN: %clang_cc1 

[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-08 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5400-5401
+SourceLocation KWLoc) {
+  if (!S.getLangOpts().CPlusPlus11)
+return;
+

royjacobson wrote:
> aaron.ballman wrote:
> > erichkeane wrote:
> > > royjacobson wrote:
> > > > erichkeane wrote:
> > > > > royjacobson wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > I think we should always warn on these, not just in C++11.
> > > > > > I'm not convinced we should. My reasoning is that we need a pretty 
> > > > > > good reason to start issuing warnings for 20 years old code. The 
> > > > > > usage of those builtins with deleted functions after C++11 is 
> > > > > > pretty broken which is a pretty good reason, but for earlier 
> > > > > > language versions they work 'fine' and if people want to use C++03 
> > > > > > I prefer leaving them at peace :)
> > > > > > 
> > > > > > People on C++03 are also probably using pretty old versions of 
> > > > > > libstdc++ and/or boost type_traits, so this could have some impact.
> > > > > > 
> > > > > > WDYT?
> > > > > > 
> > > > > warnings don't get emitted for code in header files, so at least that 
> > > > > part isn't a concern.  
> > > > Any header files, or just system headers?
> > > Sorry, yes, Phab is a mess on a cell phone... in things included as 
> > > System Headers.
> > Agreed with Erich -- warnings in system headers (but not regular headers) 
> > are silenced by default, you need to pass `-Wsystem-headers` to enable them.
> To clarify my position, I think about those builtins as an unofficial part of 
> the C++03 standard and I think we should support them as long as we support 
> C++03.
> 
> Do you think that's reasonable?
> 
> I agree we should update the documentation in this case.
I still don't see the benefit of undeprecating these in C++03. The replacement 
interfaces are available for use in C++03 mode, so there's nothing that 
prevents a user from being pushed to use the supported interfaces instead, 
right? To me, the older interfaces were not clean/correct and the replacement 
interfaces are the ones that we want people to use, and that's language mode 
agnostic.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-08 Thread Roy Jacobson via Phabricator via cfe-commits
royjacobson added inline comments.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5400-5401
+SourceLocation KWLoc) {
+  if (!S.getLangOpts().CPlusPlus11)
+return;
+

aaron.ballman wrote:
> erichkeane wrote:
> > royjacobson wrote:
> > > erichkeane wrote:
> > > > royjacobson wrote:
> > > > > aaron.ballman wrote:
> > > > > > I think we should always warn on these, not just in C++11.
> > > > > I'm not convinced we should. My reasoning is that we need a pretty 
> > > > > good reason to start issuing warnings for 20 years old code. The 
> > > > > usage of those builtins with deleted functions after C++11 is pretty 
> > > > > broken which is a pretty good reason, but for earlier language 
> > > > > versions they work 'fine' and if people want to use C++03 I prefer 
> > > > > leaving them at peace :)
> > > > > 
> > > > > People on C++03 are also probably using pretty old versions of 
> > > > > libstdc++ and/or boost type_traits, so this could have some impact.
> > > > > 
> > > > > WDYT?
> > > > > 
> > > > warnings don't get emitted for code in header files, so at least that 
> > > > part isn't a concern.  
> > > Any header files, or just system headers?
> > Sorry, yes, Phab is a mess on a cell phone... in things included as System 
> > Headers.
> Agreed with Erich -- warnings in system headers (but not regular headers) are 
> silenced by default, you need to pass `-Wsystem-headers` to enable them.
To clarify my position, I think about those builtins as an unofficial part of 
the C++03 standard and I think we should support them as long as we support 
C++03.

Do you think that's reasonable?

I agree we should update the documentation in this case.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-07 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5400-5401
+SourceLocation KWLoc) {
+  if (!S.getLangOpts().CPlusPlus11)
+return;
+

erichkeane wrote:
> royjacobson wrote:
> > erichkeane wrote:
> > > royjacobson wrote:
> > > > aaron.ballman wrote:
> > > > > I think we should always warn on these, not just in C++11.
> > > > I'm not convinced we should. My reasoning is that we need a pretty good 
> > > > reason to start issuing warnings for 20 years old code. The usage of 
> > > > those builtins with deleted functions after C++11 is pretty broken 
> > > > which is a pretty good reason, but for earlier language versions they 
> > > > work 'fine' and if people want to use C++03 I prefer leaving them at 
> > > > peace :)
> > > > 
> > > > People on C++03 are also probably using pretty old versions of 
> > > > libstdc++ and/or boost type_traits, so this could have some impact.
> > > > 
> > > > WDYT?
> > > > 
> > > warnings don't get emitted for code in header files, so at least that 
> > > part isn't a concern.  
> > Any header files, or just system headers?
> Sorry, yes, Phab is a mess on a cell phone... in things included as System 
> Headers.
Agreed with Erich -- warnings in system headers (but not regular headers) are 
silenced by default, you need to pass `-Wsystem-headers` to enable them.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5433
+// FIXME: GCC don't implement __is_trivially_destructible: Warning for this
+//   might be too noisy for now.
+// case UTT_HasTrivialDestructor:

royjacobson wrote:
> aaron.ballman wrote:
> > I'd like to know how plausible that "might" is -- Clang flags it as being 
> > deprecated, so it seems very reasonable to diagnose it as such. These 
> > diagnostics won't be triggered from system headers by default anyway, so 
> > I'm not certain if this will be too noisy in practice.
> It's used in libstdc++'s type_traits and in boost's type_traits (but we will 
> start warning on boost's type_traits anyway). So it's even if by default 
> people are not going to see it I think it's used widely enough to be 
> problematic and we shouldn't warn on this for now.
> 
> I added the libstdc++ part to the comment as well.
My feeling is: if it's deprecated and we don't warn on it, it's not actually 
deprecated. I'd rather see us warn uniformly on all the deprecated interfaces. 
System headers are free to keep using these interfaces (system headers are long 
lived), but any user code using this needs some sort of notification that 
they're using something we don't want them to use, or we will never be able to 
get rid of these interfaces (at which point, we should undeprecate them because 
we need to keep them working).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-07 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5400-5401
+SourceLocation KWLoc) {
+  if (!S.getLangOpts().CPlusPlus11)
+return;
+

royjacobson wrote:
> erichkeane wrote:
> > royjacobson wrote:
> > > aaron.ballman wrote:
> > > > I think we should always warn on these, not just in C++11.
> > > I'm not convinced we should. My reasoning is that we need a pretty good 
> > > reason to start issuing warnings for 20 years old code. The usage of 
> > > those builtins with deleted functions after C++11 is pretty broken which 
> > > is a pretty good reason, but for earlier language versions they work 
> > > 'fine' and if people want to use C++03 I prefer leaving them at peace :)
> > > 
> > > People on C++03 are also probably using pretty old versions of libstdc++ 
> > > and/or boost type_traits, so this could have some impact.
> > > 
> > > WDYT?
> > > 
> > warnings don't get emitted for code in header files, so at least that part 
> > isn't a concern.  
> Any header files, or just system headers?
Sorry, yes, Phab is a mess on a cell phone... in things included as System 
Headers.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-07 Thread Roy Jacobson via Phabricator via cfe-commits
royjacobson marked 3 inline comments as done.
royjacobson added inline comments.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5400-5401
+SourceLocation KWLoc) {
+  if (!S.getLangOpts().CPlusPlus11)
+return;
+

erichkeane wrote:
> royjacobson wrote:
> > aaron.ballman wrote:
> > > I think we should always warn on these, not just in C++11.
> > I'm not convinced we should. My reasoning is that we need a pretty good 
> > reason to start issuing warnings for 20 years old code. The usage of those 
> > builtins with deleted functions after C++11 is pretty broken which is a 
> > pretty good reason, but for earlier language versions they work 'fine' and 
> > if people want to use C++03 I prefer leaving them at peace :)
> > 
> > People on C++03 are also probably using pretty old versions of libstdc++ 
> > and/or boost type_traits, so this could have some impact.
> > 
> > WDYT?
> > 
> warnings don't get emitted for code in header files, so at least that part 
> isn't a concern.  
Any header files, or just system headers?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-06 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5400-5401
+SourceLocation KWLoc) {
+  if (!S.getLangOpts().CPlusPlus11)
+return;
+

royjacobson wrote:
> aaron.ballman wrote:
> > I think we should always warn on these, not just in C++11.
> I'm not convinced we should. My reasoning is that we need a pretty good 
> reason to start issuing warnings for 20 years old code. The usage of those 
> builtins with deleted functions after C++11 is pretty broken which is a 
> pretty good reason, but for earlier language versions they work 'fine' and if 
> people want to use C++03 I prefer leaving them at peace :)
> 
> People on C++03 are also probably using pretty old versions of libstdc++ 
> and/or boost type_traits, so this could have some impact.
> 
> WDYT?
> 
warnings don't get emitted for code in header files, so at least that part 
isn't a concern.  


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-06 Thread Roy Jacobson via Phabricator via cfe-commits
royjacobson marked 9 inline comments as done and 2 inline comments as done.
royjacobson added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticGroups.td:190
 : DiagGroup<"deprecated-dynamic-exception-spec">;
+def DeprecatedHasBuiltins : DiagGroup<"deprecated-has-builtins">;
 def DeprecatedImplementations :DiagGroup<"deprecated-implementations">;

aaron.ballman wrote:
> I wonder if we want to rename this to `deprecated-builtins` so it applies to 
> any builtin we elect to deprecate, not just ones that start with `has`. WDYT?
Sounds good to me, updated it.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:5561
+def warn_deprecated_has_builtins : Warning<
+  "the %0 compiler builtin is deprecated from C++11 onwards. Use %1 instead.">,
+  InGroup;

aaron.ballman wrote:
> erichkeane wrote:
> > cor3ntin wrote:
> > > Should we say something like "and will be removed in the future"?
> > > 
> > > "%0 is deprecated from C++11 onward. Use %1 instead." might be sufficient
> > > 
> > > 
> > Diagnostics arent sentences. Also, we wouldn't say "C++11 onward", we can 
> > just say C++11. I might suggest:
> > 
> > `builtin %0 is deprecated in C++11, use %1 instead`
> > 
> > BUT @aaron.ballman always does great at this level of bikeshedding.
> > 
> I think we might want to rename this to `warn_deprecated_builtin` and make it 
> slightly more general. I think we want to drop the mention of C++11 because 
> the documentation says these are deprecated (not deprecated in a specific 
> version) and the replacement APIs are all available pre C++11 anyway (at 
> least in Clang). How about: `builtin %0 is deprecated; use %1 instead`?
Took Aaron's version at the end.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5400-5401
+SourceLocation KWLoc) {
+  if (!S.getLangOpts().CPlusPlus11)
+return;
+

aaron.ballman wrote:
> I think we should always warn on these, not just in C++11.
I'm not convinced we should. My reasoning is that we need a pretty good reason 
to start issuing warnings for 20 years old code. The usage of those builtins 
with deleted functions after C++11 is pretty broken which is a pretty good 
reason, but for earlier language versions they work 'fine' and if people want 
to use C++03 I prefer leaving them at peace :)

People on C++03 are also probably using pretty old versions of libstdc++ and/or 
boost type_traits, so this could have some impact.

WDYT?




Comment at: clang/lib/Sema/SemaExprCXX.cpp:5426-5428
+case UTT_HasTrivialDefaultConstructor:
+  Replacement = TT_IsTriviallyConstructible;
+  break;

aaron.ballman wrote:
> This one is not documented as being deprecated (or documented at all). I 
> think it's reasonable to deprecate it, but it should probably be documented 
> in the language extensions page.
It's the `__has_trivial_constructor` builtin that unfortunately has a different 
enum name (it's named after the internal CXXRecordDecl it calls, I think).



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5433
+// FIXME: GCC don't implement __is_trivially_destructible: Warning for this
+//   might be too noisy for now.
+// case UTT_HasTrivialDestructor:

aaron.ballman wrote:
> I'd like to know how plausible that "might" is -- Clang flags it as being 
> deprecated, so it seems very reasonable to diagnose it as such. These 
> diagnostics won't be triggered from system headers by default anyway, so I'm 
> not certain if this will be too noisy in practice.
It's used in libstdc++'s type_traits and in boost's type_traits (but we will 
start warning on boost's type_traits anyway). So it's even if by default people 
are not going to see it I think it's used widely enough to be problematic and 
we shouldn't warn on this for now.

I added the libstdc++ part to the comment as well.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-06 Thread Roy Jacobson via Phabricator via cfe-commits
royjacobson updated this revision to Diff 442680.
royjacobson added a comment.

Address CR comments.
Make the switch case slightly more concise.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/CXX/dcl.decl/dcl.init/p5.cpp
  clang/test/CXX/drs/dr18xx.cpp
  clang/test/CXX/drs/dr21xx.cpp
  clang/test/CXX/special/class.copy/p12-0x.cpp
  clang/test/CXX/special/class.copy/p25-0x.cpp
  clang/test/CXX/special/class.ctor/p5-0x.cpp
  clang/test/Modules/cxx-decls.cpp
  clang/test/SemaCXX/cxx0x-defaulted-functions.cpp
  clang/test/SemaCXX/cxx11-crashes.cpp
  clang/test/SemaCXX/deprecated-builtins.cpp
  clang/test/SemaCXX/sizeless-1.cpp
  clang/test/SemaCXX/trivial-constructor.cpp
  clang/test/SemaCXX/trivial-destructor.cpp
  clang/test/SemaCXX/type-traits.cpp
  clang/test/SemaObjCXX/arc-type-traits.mm
  clang/test/SemaObjCXX/objc-weak-type-traits.mm

Index: clang/test/SemaObjCXX/objc-weak-type-traits.mm
===
--- clang/test/SemaObjCXX/objc-weak-type-traits.mm
+++ clang/test/SemaObjCXX/objc-weak-type-traits.mm
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -fobjc-weak -fobjc-runtime-has-weak -verify -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -fobjc-weak -fobjc-runtime-has-weak -verify -std=c++11 %s -Wno-deprecated-builtins
 // expected-no-diagnostics
 
 // Check the results of the various type-trait query functions on
Index: clang/test/SemaObjCXX/arc-type-traits.mm
===
--- clang/test/SemaObjCXX/arc-type-traits.mm
+++ clang/test/SemaObjCXX/arc-type-traits.mm
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -fobjc-arc -fobjc-runtime-has-weak -verify -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -fobjc-arc -fobjc-runtime-has-weak -verify -std=c++11 %s -Wno-deprecated-builtins
 // expected-no-diagnostics
 
 // Check the results of the various type-trait query functions on
Index: clang/test/SemaCXX/type-traits.cpp
===
--- clang/test/SemaCXX/type-traits.cpp
+++ clang/test/SemaCXX/type-traits.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++11 -fms-extensions -Wno-microsoft %s
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++14 -fms-extensions -Wno-microsoft %s
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++1z -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++11 -Wno-deprecated-builtins -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++14 -Wno-deprecated-builtins -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++1z -Wno-deprecated-builtins -fms-extensions -Wno-microsoft %s
 
 #define T(b) (b) ? 1 : -1
 #define F(b) (b) ? -1 : 1
Index: clang/test/SemaCXX/trivial-destructor.cpp
===
--- clang/test/SemaCXX/trivial-destructor.cpp
+++ clang/test/SemaCXX/trivial-destructor.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11 -Wno-deprecated-builtins
 // expected-no-diagnostics
 struct T1 {
 };
Index: clang/test/SemaCXX/trivial-constructor.cpp
===
--- clang/test/SemaCXX/trivial-constructor.cpp
+++ clang/test/SemaCXX/trivial-constructor.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11 -Wno-deprecated-builtins
 // expected-no-diagnostics
 struct T1 {
 };
Index: clang/test/SemaCXX/sizeless-1.cpp
===
--- clang/test/SemaCXX/sizeless-1.cpp
+++ clang/test/SemaCXX/sizeless-1.cpp
@@ -1,7 +1,7 @@
 // RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wno-unused-but-set-variable -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++98 %s
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wno-unused-but-set-variable -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++11 %s
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wno-unused-but-set-variable -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++17 %s
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wno-unused-but-set-variable -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=gnu++17 %s
+// RUN: 

[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-06 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticGroups.td:190
 : DiagGroup<"deprecated-dynamic-exception-spec">;
+def DeprecatedHasBuiltins : DiagGroup<"deprecated-has-builtins">;
 def DeprecatedImplementations :DiagGroup<"deprecated-implementations">;

I wonder if we want to rename this to `deprecated-builtins` so it applies to 
any builtin we elect to deprecate, not just ones that start with `has`. WDYT?



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:5561
+def warn_deprecated_has_builtins : Warning<
+  "the %0 compiler builtin is deprecated from C++11 onwards. Use %1 instead.">,
+  InGroup;

erichkeane wrote:
> cor3ntin wrote:
> > Should we say something like "and will be removed in the future"?
> > 
> > "%0 is deprecated from C++11 onward. Use %1 instead." might be sufficient
> > 
> > 
> Diagnostics arent sentences. Also, we wouldn't say "C++11 onward", we can 
> just say C++11. I might suggest:
> 
> `builtin %0 is deprecated in C++11, use %1 instead`
> 
> BUT @aaron.ballman always does great at this level of bikeshedding.
> 
I think we might want to rename this to `warn_deprecated_builtin` and make it 
slightly more general. I think we want to drop the mention of C++11 because the 
documentation says these are deprecated (not deprecated in a specific version) 
and the replacement APIs are all available pre C++11 anyway (at least in 
Clang). How about: `builtin %0 is deprecated; use %1 instead`?



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5400-5401
+SourceLocation KWLoc) {
+  if (!S.getLangOpts().CPlusPlus11)
+return;
+

I think we should always warn on these, not just in C++11.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5426-5428
+case UTT_HasTrivialDefaultConstructor:
+  Replacement = TT_IsTriviallyConstructible;
+  break;

This one is not documented as being deprecated (or documented at all). I think 
it's reasonable to deprecate it, but it should probably be documented in the 
language extensions page.



Comment at: clang/lib/Sema/SemaExprCXX.cpp:5433
+// FIXME: GCC don't implement __is_trivially_destructible: Warning for this
+//   might be too noisy for now.
+// case UTT_HasTrivialDestructor:

I'd like to know how plausible that "might" is -- Clang flags it as being 
deprecated, so it seems very reasonable to diagnose it as such. These 
diagnostics won't be triggered from system headers by default anyway, so I'm 
not certain if this will be too noisy in practice.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-06 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added subscribers: aaron.ballman, erichkeane.
erichkeane added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:305
 
+- Some type traits builtins like ``__has_trivial_assign`` have been documented
+  as deprecated for a while, because their semantics don't mix well with 
post-C++11 type





Comment at: clang/docs/ReleaseNotes.rst:306
+- Some type traits builtins like ``__has_trivial_assign`` have been documented
+  as deprecated for a while, because their semantics don't mix well with 
post-C++11 type
+  traits. Clang now emits deprecation warnings for them under the flag 
``-Wdeprecated-has-builtins``.





Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:5561
+def warn_deprecated_has_builtins : Warning<
+  "the %0 compiler builtin is deprecated from C++11 onwards. Use %1 instead.">,
+  InGroup;

cor3ntin wrote:
> Should we say something like "and will be removed in the future"?
> 
> "%0 is deprecated from C++11 onward. Use %1 instead." might be sufficient
> 
> 
Diagnostics arent sentences. Also, we wouldn't say "C++11 onward", we can just 
say C++11. I might suggest:

`builtin %0 is deprecated in C++11, use %1 instead`

BUT @aaron.ballman always does great at this level of bikeshedding.




Comment at: clang/lib/Sema/SemaExprCXX.cpp:5454
 
+  IssueBuiltinDeprecationWarningIfNeeded(*this, Kind, KWLoc);
+




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-06 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:5561
+def warn_deprecated_has_builtins : Warning<
+  "the %0 compiler builtin is deprecated from C++11 onwards. Use %1 instead.">,
+  InGroup;

Should we say something like "and will be removed in the future"?

"%0 is deprecated from C++11 onward. Use %1 instead." might be sufficient





Comment at: clang/lib/Sema/SemaExprCXX.cpp:5432
+  break;
+// FIXME: GCC don't implement __is_trivially_destructible: Warning for this
+//   might be too noisy for now.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129170/new/

https://reviews.llvm.org/D129170

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-05 Thread Roy Jacobson via Phabricator via cfe-commits
royjacobson created this revision.
Herald added a project: All.
royjacobson requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Some compiler provided type traits like __has_trivial_constructor have been 
documented
as deprecated for quite some time.
Still, some people apparently still use them, even though mixing them with 
concepts
and with deleted functions leads to weird results. There's also disagreement 
about some
edge cases between GCC (which Clang claims to follow) and MSVC.

This patch adds deprecation warnings for the usage of those builtins, except 
for __has_trivial_destructor
which doesn't have a GCC alternative.

I made the warning on by default, so I had to silence it for some tests but 
it's not too many.

Some (decade old) history of issues with those builtins:
https://github.com/llvm/llvm-project/issues/18187
https://github.com/llvm/llvm-project/issues/18559
https://github.com/llvm/llvm-project/issues/22161
https://github.com/llvm/llvm-project/issues/33063

The abseil usage of them that triggered me to add this warning:
https://github.com/abseil/abseil-cpp/issues/1201

Weird interaction of those builtins with C++20's conditionally trivial special 
member functions:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106085


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D129170

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/CXX/dcl.decl/dcl.init/p5.cpp
  clang/test/CXX/drs/dr18xx.cpp
  clang/test/CXX/drs/dr21xx.cpp
  clang/test/CXX/special/class.copy/p12-0x.cpp
  clang/test/CXX/special/class.copy/p25-0x.cpp
  clang/test/CXX/special/class.ctor/p5-0x.cpp
  clang/test/Modules/cxx-decls.cpp
  clang/test/SemaCXX/cxx0x-defaulted-functions.cpp
  clang/test/SemaCXX/cxx11-crashes.cpp
  clang/test/SemaCXX/deprecated-builtins.cpp
  clang/test/SemaCXX/sizeless-1.cpp
  clang/test/SemaCXX/trivial-constructor.cpp
  clang/test/SemaCXX/trivial-destructor.cpp
  clang/test/SemaCXX/type-traits.cpp
  clang/test/SemaObjCXX/arc-type-traits.mm
  clang/test/SemaObjCXX/objc-weak-type-traits.mm

Index: clang/test/SemaObjCXX/objc-weak-type-traits.mm
===
--- clang/test/SemaObjCXX/objc-weak-type-traits.mm
+++ clang/test/SemaObjCXX/objc-weak-type-traits.mm
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -fobjc-weak -fobjc-runtime-has-weak -verify -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -fobjc-weak -fobjc-runtime-has-weak -verify -std=c++11 %s -Wno-deprecated-has-builtins
 // expected-no-diagnostics
 
 // Check the results of the various type-trait query functions on
Index: clang/test/SemaObjCXX/arc-type-traits.mm
===
--- clang/test/SemaObjCXX/arc-type-traits.mm
+++ clang/test/SemaObjCXX/arc-type-traits.mm
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -fobjc-arc -fobjc-runtime-has-weak -verify -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -fobjc-arc -fobjc-runtime-has-weak -verify -std=c++11 %s -Wno-deprecated-has-builtins
 // expected-no-diagnostics
 
 // Check the results of the various type-trait query functions on
Index: clang/test/SemaCXX/type-traits.cpp
===
--- clang/test/SemaCXX/type-traits.cpp
+++ clang/test/SemaCXX/type-traits.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++11 -fms-extensions -Wno-microsoft %s
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++14 -fms-extensions -Wno-microsoft %s
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++1z -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++11 -Wno-deprecated-has-builtins -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++14 -Wno-deprecated-has-builtins -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++1z -Wno-deprecated-has-builtins -fms-extensions -Wno-microsoft %s
 
 #define T(b) (b) ? 1 : -1
 #define F(b) (b) ? -1 : 1
Index: clang/test/SemaCXX/trivial-destructor.cpp
===
--- clang/test/SemaCXX/trivial-destructor.cpp
+++ clang/test/SemaCXX/trivial-destructor.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11 -Wno-deprecated-has-builtins
 // expected-no-diagnostics
 struct T1 {
 };
Index: clang/test/SemaCXX/trivial-constructor.cpp
===
--- clang/test/SemaCXX/trivial-constructor.cpp
+++ clang/test/SemaCXX/trivial-constructor.cpp
@@ -1,4