[cfe-commits] [Patch] Implement compiler intrinsics for MSVC 2012 type_traits

[Ryan Molden]

On Fri, Nov 9, 2012 at 9:13 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> On Thu, Nov 8, 2012 at 5:49 PM, Ryan Molden <ryanmolden at gmail.com> wrote:
> > This is a re-submission of an older proposed patch
> > (
> http://www.mail-archive.com/cfe-commits@cs.uiuc.edu/msg55616/0001-Added-support-for-MSVC-2012-type-traits-used-in-stan.patch
> )
> > that João hadn't had time to write tests for (which were requested with
> the
> > original submission review).
> >
> > The only changes I made from the original (apart from adding tests) was
> to
> > take out the bail-out for hasTrivialMoveAssignment from
> > UTT_HasNothrowMoveAssign in EvaluateUnaryTypeTrait (in
> > lib\Sema\SemaExprCXX.cpp).
> >
> > My reasoning was that trivial move assignment operators (which I
> understand
> > to be implicitly generated ones, please correct me if this is mistaken)
> can
> > actually have non-empty exception specifiers if any of the member
> > move-assignment operators they invoke have such non-empty exception
> > specifiers.
> >
> > Specifically:
> >
> > n3376 15.4 [except.spec]/14
> >
> > An inheriting constructor (12.9) and an implicitly declared special
> member
> > function (Clause 12) have an exception-specification. If f is an
> inheriting
> > constructor or an implicitly declared default constructor, copy
> constructor,
> > move constructor, destructor, copy assignment operator, or move
> assignment
> > operator, its implicit exception-specification specifies the type-id T if
> > and only if T is allowed by the exception-specification of a function
> > directly invoked by f’s implicit definition; f allows all exceptions if
> any
> > function it directly invokes allows all exceptions, and f has the
> > exception-specification noexcept(true) if every function it directly
> invokes
> > allows no exceptions. [ Note: An instantiation of an inheriting
> constructor
> > template has an implied exception-specification as if it were a
> non-template
> > inheriting constructor.]
> >
> > so I would expect this class (HasMemberThrowMoveAssign) to fail for
> > std::is_nothrow_move_assignable:
> >
> > struct NonPOD { NonPOD(int); }; enum Enum { EV }; struct POD { Enum e;
> int
> > i; float f; NonPOD* p; };
> >
> > struct HasThrowMoveAssign { HasThrowMoveAssign& operator =(const
> > HasThrowMoveAssign&&) throw(POD); };
> > struct HasMemberThrowMoveAssign { HasThrowMoveAssign member; };
> >
> > even though it should have a trivial move-assignment operator generated.
> > Please correct me if I am mistaken here as my standards reading FU
> is...not
> > strong.
>
> You are mistaken here ;-)
>
> HasMemberThrowMoveAssign's move assignment is not trivial because it
> calls a non-trivial move assignment operator. It is possible to have a
> throwing trivial move assignment operator, but only if it is deleted.
> In that case, the trait should presumbly return false.
>

Great, thanks for the catch. So it seems that having the early bail-out for
things with trivial move assignment operators is correct. I put it back in
and all tests are still passing (I thought one of them was failing before I
took it out, but that was a week+ ago, so perhaps I am just
mis-remembering).

It isn't clear how I would make a 'throwing trivial move assignment
operator', if you have suggestions I can certainly add a test for it.

New patch attached that simply syncs to tip and adds back the bail-out for
types with a trivial move-assignment operator.

Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121111/a8457c36/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Support-For-MSVC-2012-Type-Traits-For-STL.patch
Type: application/octet-stream
Size: 16629 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121111/a8457c36/attachment.obj>