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

[Ryan Molden]

 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: cfe-commits at cs.uiuc.edu; sabre at nondot.org
Subject: Re: [cfe-commits] [Patch] Implement compiler intrinsics for
MSVC 2012 type_traits
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-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;">cfe-commits at cs.uiuc.edu; sabr=
e at nondot.org</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:richard at metafoo.co.uk" target=
=3D"_blank">richard at metafoo.co.uk</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:ryanmolden at gmail.com">ryanmolden at gmail.com</=
a>> wrote:<br>
> This is a re-submission of an older proposed patch<br>
> (<a href=3D"http://www.mail-archive.com/cfe-commits@cs.uiuc.edu/msg556=
16/0001-Added-support-for-MSVC-2012-type-traits-used-in-stan.patch" target=
=3D"_blank">http://www.mail-archive.com/cfe-commits@cs.uiuc.edu/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--