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

[Douglas Gregor]

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.

> 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.

> 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. 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.

	- Doug