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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
