[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