[cfe-dev] Back to work: attributes

[Douglas Gregor]

On Jul 7, 2011, at 4:18 AM, Olaf Krzikalla wrote:

> Hi @clang,
> 
> it's been a while that we discussed the implementation of attributes.
> Since Sean didn't chime I guess he doesn't work on attributes anymore.
> Now hopefully I've found the week I've planned to need to get that stuff on the right track. But before I start there are a lot of questions and issues to clarify.
> 
> 1. How resilient ought to be the PCH serialization? Suppose a user-defined attribute that is supported by a particular plugin. The interesting cases are when the plugin is loaded only either during PCH generation or usage. Currently attributes are serialized by their actual semantic properties. But a more resilient implementation would just store a (simplified) token stream and regenerate the attributes from that stream during PCH loading. This approach has the additional benefit that user-defined attributes don't need to define serialization functions.

A simplified token stream feels like overkill for user-defined attributes. The bitcode format can already handle variable-length records of arbitrary data, so if we serialize user-defined attributes the same way as we currently serialize built-in attributes (albeit with some more general attribute naming scheme), that will be sufficient to skip any unrecognized attributes.

> 2. What is the point of InheritableAttr? The Inherited property is already in Attr, we could also stream it for every attr (e.g. by bit-masking it with Attr::Kind). On the other hand it seems to be used only with DLLImportAttr, so actually we could also remove InheritableAttr altogether (and move the property to DLLImportAttr).

Attributes that are inheritable (i.e., derive from InheritableAttr) are automatically merged from a prior declaration of an entity to a later declaration; see SemaDecl.cpp's mergeDeclAttributes().

The Inherited property says whether that instance of the attribute was inherited from a previous declaration (rather than being written directly in the source).

> 3. Just btw: If I haven't overlooked something, then openmp pragmas are still a TODO. It would be interesting to see them working in clang because in the end they have to solve the same problem that I actually have (and that is the root for my efforts on attributes): parse an expression inside a pragma. What are the plans regarding openmp?

There are no plans for OpenMP per se, and I don't know of anyone else working on OpenMP support.

	- Doug