[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
>

Ping. Should anyone specific be looking at this? Are there people
specifically focusing on Clang on Windows perhaps? I was looking to wrap
this one up so I could move on to the next problem with parsing 2012 STL
headers.

Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121116/7ae38645/attachment.html>