[PATCH] D34198: Fix __has_trivial_destructor crash when the type is incomplete with unknown array bounds.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith accepted this revision.
rsmith added inline comments.


================
Comment at: lib/Sema/SemaExprCXX.cpp:4128
+        return true;
+    }
+
----------------
rjmccall wrote:
> puneetha wrote:
> > rjmccall wrote:
> > > I don't understand the difference you're creating between traits here.  Three specific traits about destructibility allow incomplete array types regardless of whether the base type is incomplete, but the rest do not?
> > > 
> > > Anyway, I think what you want here is basically just:
> > > 
> > >   if (auto ArrayTy = S.Context.getAsIncompleteArrayType(ArgTy)) {
> > >     ArgTy = ArrayTy->getElementType();
> > >   }
> > Of my understanding, these traits are defined by MSVC. There is no mention of them in the GCC type-traits documentation. For these traits, GCC lets us pass an array of incomplete bounds for any base type, complete or incomplete.
> > 
> > Please correct me if I am wrong.
> I see.  If we're matching GCC bug-for-bug, it doesn't really matter if the behavior seems inconsistent.
Generally: when the C++ standard has a trait named `std::foo` and Clang has a `__foo` builtin, the latter is a complete implementation of the former (and if other compilers have bugs in their implementations, we are not bug-for-bug compatible). That covers the `UTT_Is*` traits here.

The other traits are typically extensions from other vendors, often used to implement pre-standard names for traits. Many of those are considered deprecated, and we try to be mostly bug-for-bug compatible with GCC or MSVC when implementing them. That covers the `UTT_Has*` traits here.

Per commentary in PR33232, MSVC's STL has nearly entirely moved off the deprecated traits, so it's mostly GCC compatibility we care about here.


https://reviews.llvm.org/D34198