Actually attaching the patch this time :( Ryan
On Wed, Nov 7, 2012 at 7:57 PM, Ryan Molden <[email protected]> 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/[email protected]/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 >
Support-For-MSVC-2012-Type-Traits-For-STL.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
