[cfe-dev] [clang] declspec(property...) advice

[Argyrios Kyrtzidis]

On Feb 7, 2011, at 10:35 AM, John McCall wrote:

> On Feb 7, 2011, at 10:15 AM, Argyrios Kyrtzidis wrote:
>> On Feb 6, 2011, at 8:40 AM, Eric Niebler wrote:
>> On 2/4/2011 4:00 PM, Eric Niebler wrote:
>>> 
>>> I'd like to share my current thinking on the property issue. I encourage
>>> any and all interested parties to jump in.
>>> 
>>> Above, John McCall suggests modifying BuildBinOp to Do Something. I
>>> think that something is to programatically rewrite the AST into the
>>> appropriate getter and setter calls. Ditto for BuildUnaryOp. So for
>>> instance, for this code:
>>> 
>>> ++obj.property;
>>> 
>>> when BuildUnaryOp gets passed a PropertyRefExpr and the
>>> pre-increment op code, it builds the AST for this:
>>> 
>>> obj.setProperty(obj.getPropery() + 1)
>> 
>> I'm not sure I understand why we have to have so expicit AST nodes, traditionally the nodes were as close to the source code as possible.
>> Can't we do semantic checking otherwise ? Do we need to simplify it to make it easier for codegen ?
>> One could argue that we should rewrite all
>> ++variable;
>> to
>> variable = variable + 1;
> 
> Unfortunately, compound assignments have semantics that are somewhat more complicated than a simple top-down walk through a syntax tree:  we evaluate the LHS as an l-value, coerce the loaded value to the type of the operation, perform the operation, coerce the result back to the l-value type, and store that in.  We kindof finesse this right now — clients like IR generation have to duplicate the coercion logic that normally Sema would do.  That's acceptable for most things only because there's a limit to how complicated this analysis can get.  With property reference l-values, however, the l-value accesses are secretly function calls;  we're not getting all the cases right even for Objective-C property references (e.g. with getters and setters of asymmetric type or of C++ class type), and I expect that's probably a non-starter for a C++-centered property system.
> 
> John.
> 


> we're not getting all the cases right even for Objective-C property references (e.g. with getters and setters of asymmetric type or of C++ class type)

Oh wow, no checking for Objective-C props, we leave it at the mercy of codegen which either emits bogus IR or crashes, e.g:

@interface Foo
-(float)myfo;
-(void)setMyfo: (int)p;
@end

void bar(Foo *x) {
  x.myfo++;
}

Call parameter type does not match function signature!
  %6 = fadd float %5, 1.000000e+00
 i32  call void bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to void (i8*, i8*, i32)*)(i8* %8, i8* %7, float %6)
Broken module found, compilation aborted!


Ok, being more explicit is goodness but could we be consistent about it ? If we have the mechanism in place to rewrite compound assignments with AST nodes that are explicit but also indicate that there was a compound assignment in source code,
could we use it consistently for all compound assignments, not just properties, thereby simplifying a bit clients like codegen and the analyzer ?

-Argiris