[cfe-dev] Back to work: attributes

Olaf Krzikalla Olaf.Krzikalla at tu-dresden.de
Thu Jul 7 04:18:49 PDT 2011


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.

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

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?


OK, the rest seems rather clear to me. The current implementation is 
quite incomplete and I guess I have to put some work in ClangAttrEmitter 
too in order to get proper parsing and semantic checking generated by 
tblgen.


Best regards
Olaf Krzikalla



More information about the cfe-dev mailing list