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

[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