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

[Eric Niebler]

On 12/8/2010 1:16 PM, Douglas Gregor wrote:
> 
> On Dec 8, 2010, at 9:56 AM, Eric Niebler wrote:
> 
>> I'm currently working on getting the front-end to eat Microsoft's 
>> __declspec(property...) extension.
>> 
>> http://msdn.microsoft.com/en-us/library/yhfk0thd%28v=VS.100%29.aspx
>>
>> I've gotten things to the point where I can parse it and generate a
>> PropertyAttr attached to the FieldDecl. The PropertyAttr has two 
>> string attributes representing the name of the getter and setter 
>> member functions. I am wondering if this is the best way to 
>> represent this in the AST. My impression of how the feature is
>> used is that expressions are rewritten:
>> 
>> "a = x.foo"  becomes  "a = x.getFoo()" "x.foo = a"  becomes 
>> "x.setFoo(a)" "x.foo += 1" becomes  "x.setFoo(x.getFoo() + 1)"
>> 
>> Also, when generating the layout for the class and the 
>> constructors/destructors/assign methods, these pseudo-fields
>> should be ignored. These are all non-trivial rewrites. A few
>> questions:
>> 
>> 1) In your opinion, is having a normal FieldDecl in the AST with an
>> attribute the way to go? Or should there be an entirely different
>> kind of Decl for these pseudo-fields?
> 
> There should be an entirely different kind of Decl for these 
> properties, because they really have nothing to do with fields once 
> we've gotten past their syntax. It'll be a subclass of ValueDecl, 
> much like IndirectFieldDecl or ObjCPropertyDecl.

OK, makes sense.

>> 2) If the attribute is the right approach, is storing the getters 
>> and setters as strings sensible? FWIW, Microsoft doesn't catch 
>> typos in the getter/setter declaration until the property is 
>> actually referenced, which seems to suggest that its doing a
>> fairly primitive rewrite at the point of use. So strings would
>> work, IIUC. It does not eagerly perform name lookup of the getters
>> and setters within the class definition.
> 
> It makes sense to delay the lookup of the get/put names until after 
> the class is defined (like we do with default arguments and inline 
> member function bodies), but I find it really gross that name lookup 
> doesn't occur until the property is actually referenced.

I agree, it's a bit gross. I can't think of a case where performing
name-lookup at the end of the class definition would produce different
results, but I'm a bit wary of trying to be smarter than the MS compiler
when the ultimate goal is feature parity with MS.

>> 3) Where should the rewrite happen? Is it OK to leave in
>> references to the pseudo-field in the AST, or should the AST
>> reflect what will actually be executed -- invocations of the
>> getters and setters? My instinct tells me that the AST should have
>> the pseudo-field, not the getters and setters. Anything else might 
>> confuse things like IDEs.
> 
> The AST should have the pseudo-field (possibly with a special 
> "MSPropertyRefExpr" expression type to reference them), and we
> should introduce implicit AST nodes (e.g., an ImplicitCastExpr
> wrapping a call) to handle the get and put calls. 

I'm afraid I didn't follow that.

> You're in luck,
> though: Objective-C has properties, and John McCall is currently
> refactoring lvalue-to-rvalue conversions to make properties (and
> other constructs) more explicit and cleaner. You should be able to
> use the Objective-C property implementation as a guide and follow
> what John is currently doing to implement this feature.

OK, then I might just put off further work on this feature until the
refactorization is done and I have John's work to crib from.

John, can you please alert me when your work in this area is done?

Thanks,

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com