2012 type_traits MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=047d7b676eb4798ada04ce3c7e18
--047d7b676eb4798ada04ce3c7e18 Content-Type: multipart/alternative; boundary=047d7b676eb4798ad404ce3c7e16 --047d7b676eb4798ad404ce3c7e16 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Any more feedback / ideas on this? If not could someone submit it? I don't have submission privileges Ryan From: Ryan Molden Sent: 11/11/2012 10:38 AM To: Richard Smith Cc: [email protected]; [email protected] Subject: Re: [cfe-commits] [Patch] Implement compiler intrinsics for MSVC 2012 type_traits 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-s= upport-for-MSVC-2012-type-traits-used-in-stan.patch > ) > > that Jo=C3=A3o 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=E2=80=99s implicit definition; f allows all excep= tions 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 =3D(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 --047d7b676eb4798ad404ce3c7e16 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <html><head><meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Cont= ent-Type"></head><body><div><div style=3D"font-family: Calibri,sans-serif; = font-size: 11pt;">Any more feedback / ideas on this? If not could someone s= ubmit it? I don't have submission privileges<br><br>Ryan<br></div></div><hr= ><span style=3D"font-family: Tahoma,sans-serif; font-size: 10pt; font-weigh= t: bold;">From: </span><span style=3D"font-family: Tahoma,sans-serif; font-= size: 10pt;">Ryan Molden</span><br><span style=3D"font-family: Tahoma,sans-= serif; font-size: 10pt; font-weight: bold;">Sent: </span><span style=3D"fon= t-family: Tahoma,sans-serif; font-size: 10pt;">11/11/2012 10:38 AM</span><b= r><span style=3D"font-family: Tahoma,sans-serif; font-size: 10pt; font-weig= ht: bold;">To: </span><span style=3D"font-family: Tahoma,sans-serif; font-s= ize: 10pt;">Richard Smith</span><br><span style=3D"font-family: Tahoma,sans= -serif; font-size: 10pt; font-weight: bold;">Cc: </span><span style=3D"font= -family: Tahoma,sans-serif; font-size: 10pt;">[email protected]; sabr= [email protected]</span><br><span style=3D"font-family: Tahoma,sans-serif; font-= size: 10pt; font-weight: bold;">Subject: </span><span style=3D"font-family:= Tahoma,sans-serif; font-size: 10pt;">Re: [cfe-commits] [Patch] Implement c= ompiler intrinsics for MSVC 2012 type_traits</span><br><br></body></html><b= r><br><div class=3D"gmail_quote">On Fri, Nov 9, 2012 at 9:13 PM, Richard Sm= ith <span dir=3D"ltr"><<a href=3D"mailto:[email protected]"; target= =3D"_blank">[email protected]</a>></span> wrote:<br><blockquote clas= s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= ding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Thu, Nov 8, 2012 at 5:49 PM, Rya= n Molden <<a href=3D"mailto:[email protected]";>[email protected]</= a>> wrote:<br> > This is a re-submission of an older proposed patch<br> > (<a href=3D"http://www.mail-archive.com/[email protected]/msg556= 16/0001-Added-support-for-MSVC-2012-type-traits-used-in-stan.patch" target= =3D"_blank">http://www.mail-archive.com/[email protected]/msg55616/00= 01-Added-support-for-MSVC-2012-type-traits-used-in-stan.patch</a>)<br> > that Jo=C3=A3o hadn't had time to write tests for (which were requ= ested with the<br> > original submission review).<br> ><br> > The only changes I made from the original (apart from adding tests) wa= s to<br> > take out the bail-out for hasTrivialMoveAssignment from<br> > UTT_HasNothrowMoveAssign in EvaluateUnaryTypeTrait (in<br> > lib\Sema\SemaExprCXX.cpp).<br> ><br> > My reasoning was that trivial move assignment operators (which I under= stand<br> > to be implicitly generated ones, please correct me if this is mistaken= ) can<br> > actually have non-empty exception specifiers if any of the member<br> > move-assignment operators they invoke have such non-empty exception<br= > > specifiers.<br> ><br> > Specifically:<br> ><br> > n3376 15.4 [except.spec]/14<br> ><br> > An inheriting constructor (12.9) and an implicitly declared special me= mber<br> > function (Clause 12) have an exception-specification. If f is an inher= iting<br> > constructor or an implicitly declared default constructor, copy constr= uctor,<br> > move constructor, destructor, copy assignment operator, or move assign= ment<br> > operator, its implicit exception-specification specifies the type-id T= if<br> > and only if T is allowed by the exception-specification of a function<= br> > directly invoked by f=E2=80=99s implicit definition; f allows all exce= ptions if any<br> > function it directly invokes allows all exceptions, and f has the<br> > exception-specification noexcept(true) if every function it directly i= nvokes<br> > allows no exceptions. [ Note: An instantiation of an inheriting constr= uctor<br> > template has an implied exception-specification as if it were a non-te= mplate<br> > inheriting constructor.]<br> ><br> > so I would expect this class (HasMemberThrowMoveAssign) to fail for<br= > > std::is_nothrow_move_assignable:<br> ><br> > struct NonPOD { NonPOD(int); }; enum Enum { EV }; struct POD { Enum e;= int<br> > i; float f; NonPOD* p; };<br> ><br> > struct HasThrowMoveAssign { HasThrowMoveAssign& operator =3D(const= <br> > HasThrowMoveAssign&&) throw(POD); };<br> > struct HasMemberThrowMoveAssign { HasThrowMoveAssign member; };<br> ><br> > even though it should have a trivial move-assignment operator generate= d.<br> > Please correct me if I am mistaken here as my standards reading FU is.= ..not<br> > strong.<br> <br> </div></div>You are mistaken here ;-)<br> <br> HasMemberThrowMoveAssign's move assignment is not trivial because it<br= > calls a non-trivial move assignment operator. It is possible to have a<br> throwing trivial move assignment operator, but only if it is deleted.<br> In that case, the trait should presumbly return false.<br> </blockquote></div><br><div>Great, thanks for the catch. So it seems that h= aving 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 per= haps I am just mis-remembering).</div> <div><br></div><div>It isn't clear how I would make a 'throwing tri= vial move assignment operator', if you have suggestions I can certainly= add a test for it.</div><div><br></div><div>New patch attached that simply= syncs to tip and adds back the bail-out for types with a trivial move-assi= gnment operator.</div> <div><br></div><div>Ryan</div> --047d7b676eb4798ad404ce3c7e16-- --047d7b676eb4798ada04ce3c7e18-- _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
