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

[Ryan Molden]

Actually attaching the patch this time :(

Ryan

On Wed, Nov 7, 2012 at 7:57 PM, Ryan Molden <ryanmolden at gmail.com> wrote:

> Re-sending, sorry if this is a duplicate, I never saw my other post show
> up. I have read first posts take awhile to be approved, but it has been a
> few days now, so I am assuming it was not received and sending again.
>
> 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.
>
> I have spot checked this against VS 2012 the best I can, they don't
> generate implicit move-assign yet so most all the unit tests, run against
> MSVC 2012 would fail because most of the types in the tests have implicit
> move-assigns or can't have user defined move assigns (i.e. the scalar
> types).
>
> It isn't clear if scalar types should be passing
> is_nothrow_move_assignable, it seems, conceptually, they should trivially
> pass muster. I tried reading the standard but it isn't entirely clear to
> me. They talk about move-assignment applying to objects, but then define
> objects as something with storage, which scalars certainly posses :) If
> anyone can clarify things like int, enum, pointer to member, and their
> expected results for is_nothrow_move_assignable I am happy to update any
> test. Or if you can suggest anything else I missed.
>
> Ryan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121107/7408215c/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: 16562 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121107/7408215c/attachment.obj>