[cfe-commits] r94826 - in /cfe/trunk: lib/AST/Expr.cpp lib/Sema/SemaInit.cpp lib/Sema/SemaInit.h test/CodeGenCXX/reference-init.cpp

[Fariborz Jahanian]

On Jan 30, 2010, at 11:44 AM, Douglas Gregor wrote:

>
>
> Sent from my iPhone
>
> On Jan 30, 2010, at 11:11 AM, Fariborz Jahanian  
> <fjahanian at apple.com> wrote:
>
>>
>> On Jan 29, 2010, at 2:58 PM, Douglas Gregor wrote:
>>
>>>
>>> On Jan 29, 2010, at 2:53 PM, Eli Friedman wrote:
>>>
>>>> On Fri, Jan 29, 2010 at 2:05 PM, Douglas Gregor  
>>>> <dgregor at apple.com> wrote:
>>>>>
>>>>> On Jan 29, 2010, at 1:36 PM, Eli Friedman wrote:
>>>>>
>>>>>> On Fri, Jan 29, 2010 at 1:12 PM, Chris Lattner <clattner at apple.com 
>>>>>> > wrote:
>>>>>>>
>>>>>>> On Jan 29, 2010, at 11:14 AM, Douglas Gregor wrote:
>>>>>>>
>>>>>>>> Author: dgregor
>>>>>>>> Date: Fri Jan 29 13:14:02 2010
>>>>>>>> New Revision: 94826
>>>>>>>>
>>>>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=94826&view=rev
>>>>>>>> Log:
>>>>>>>> Fix reference binding of const lvalue references to bit- 
>>>>>>>> fields, which
>>>>>>>> requires a temporary. Previously, we were building an  
>>>>>>>> initialization
>>>>>>>> sequence that bound to the bit-field as if it were a real  
>>>>>>>> lvalue. Note
>>>>>>>> that we previously (and still) diagnose binding of non-const
>>>>>>>> references to bit-fields, as we should.
>>>>>>>
>>>>>>> Does this also work for opencl vector elements?  Something  
>>>>>>> like this:
>>>>>>>
>>>>>>>
>>>>>>> float &x = myfloat4.x;
>>>>>>>
>>>>>>> should be invalid, but:
>>>>>>> float x = myfloat4.x;
>>>>>>>
>>>>>>> is ok.  Very similar to bitfields,
>>>>>>
>>>>>> We don't check for it at all... we silently build a temporary  
>>>>>> for the following:
>>>>>> typedef int V __attribute((ext_vector_type(4)));
>>>>>> V x;
>>>>>> void a() { int& y = x[0]; }
>>>>>
>>>>> BUG! I'll take a look when I can. Thanks Chris, Eli.
>>>>>
>>>>>> I don't know enough ObjC to make a testcase, but I think the same
>>>>>> issue affects ObjC properties.
>>>>>
>>>>>
>>>>> It shouldn't, because an ObjCPropertyRefExpr is not an lvalue.  
>>>>> However, I'll still test it :)
>>>>>
>>>>>     - Doug
>>>>
>>>> Umm, from Expr::isLvalueInternal:
>>>>
>>>> case ObjCPropertyRefExprClass: // FIXME: check if read-only  
>>>> property.
>>>> return LV_Valid;
>>>
>>>
>>> Oh, weird. I was looking at the other places where we check for  
>>> ObjCPropertyRefExpr.... looks like I'll need to dig into this one  
>>> further.
>>
>> It is an lvalue; similary in many aspects to MemRefExpr:
>>
>> [jahan8:~] fjahania% cat p.m
>> @interface B
>> @property int MyProp;
>> @end
>>
>> int main()
>> {
>> B *b;
>> b.MyProp = 100;
>> }
>
> Sure, but it's an lvalue without an underlying object, so this  
> should be I'll-formed:
>
>  int & ir = b.MyProp;
>
> While this needs to call the getter and bind to the resulting  
> temporary:
>
>  const int & ir = b.MyProp;

We haven't addressed all property dot-syntax access issues in c++.  
They should follow the c++
semantics. Please file bugzilla PR, if your are not seeing the  
expected behavior.
- Fariborz

>
>  - Doug
>>