[cfe-commits] r138715 - in /cfe/trunk: lib/Sema/SemaExpr.cpp test/CXX/special/class.temporary/p1.cpp

[John McCall]

On Aug 28, 2011, at 2:34 AM, Johannes Schaub wrote:

> John McCall wrote:
> 
>> On Aug 27, 2011, at 4:15 PM, Johannes Schaub wrote:
>>> John McCall wrote:
>>>> Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
>>>> URL:
>>>> http://llvm.org/viewvc/llvm-
>>> 
> project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=138715&r1=138714&r2=138715&view=diff
>>>> 
>>> 
> ==============================================================================
>>>> --- cfe/trunk/lib/Sema/SemaExpr.cpp (original) +++
>>>> cfe/trunk/lib/Sema/SemaExpr.cpp Sat Aug 27 17:06:17 2011 @@ -443,9
>>>> +443,15 @@
>>>>  if (Ty->isSpecificBuiltinType(BuiltinType::Float))
>>>>    E = ImpCastExprToType(E, Context.DoubleTy, CK_FloatingCast).take();
>>>> 
>>>> -  // C++ includes lvalue-to-rvalue conversion as a default argument
>>>> -  // promotion.  If we have a gl-value, initialize a temporary.
>>>> -  if (getLangOptions().CPlusPlus && E->isGLValue()) {
>>>> +  // C++ performs lvalue-to-rvalue conversion as a default argument
>>>> +  // promotion.  If we still have a gl-value after usual unary
>>>> +  // conversion, we must have an l-value of class type, so we need to
>>>> +  // initialize a temporary.  For compatibility reasons, however, we
>>>> +  // don't want to do this in unevaluated contexts; otherwise we
>>>> +  // reject metaprograms which work by passing uncopyable l-values to
>>>> +  // variadic functions.
>>> 
>>> 4.1p2 of the C++11 FDIS says:
>>> 
>>> "When an lvalue-to-rvalue conversion occurs in an unevaluated operand or
>>> a subexpression thereof (Clause 5) the value contained in the referenced
>>> object is not accessed. Otherwise ...".
>>> 
>>> C++03 is much less precise on the entire conversion wrt class types, but
>>> said if the expression occurs within the operand of a sizeof "the value
>>> contained in the referenced object is not accessed". I think the FDIS
>>> text will be a good reference to put on that comment.
>> 
>> I'm not sure how this applies.  I agree that the lvalue-to-rvalue
>> conversion, if well-formed, does not access the object if it appears in an
>> unevaluated
>> context.  However, the conversion is not necessarily well-formed, and
>> normally that's checked even in unevaluated contexts.
>> 
> 
> Not only is the value not accessed at runtime, but there is also no copy 
> initialization done at all. That's what is explicit in the C++0x FDIS. 
> That's the purpose of "Otherwise [if we are in an evaluated context], ...".

Ah, I see what you mean.  The rest of that section after your quote does
make the intent much clearer;  "is not accessed" makes it sound like
it's just talking about runtime behavior.

I will adjust the comment.

John.