> > On Fri, Nov 9, 2012 at 9:13 PM, Richard Smith <[email protected]>wrote: > >> On Thu, Nov 8, 2012 at 5:49 PM, Ryan Molden <[email protected]> wrote: >> > 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. >> >> 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
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
