[cfe-dev] parsing code snippets

[Douglas Gregor]

On May 10, 2011, at 3:59 AM, Olaf Krzikalla wrote:

> At first I second Sebastian. If you provide a plugin interface then you definitely want to support dynamic handling of attributes.
> 
> At second, if you think about the general picture, then dynamic handling actually boils down to two customizeable steps: parsing and semantic checking of arguments.
> Up to the parsing of arguments: IMHO there are three types of arguments: no argument, expressions and type-ids (which one did I forget? - ah, yes, a special one: VersionTuple). For arguments of these types simply declarations in one way or another have to be sufficient. A fourth type would be "user-defined". In that case a handler function similiar to PragmaHandler::HandlePragma is called with the Preprocessor as an argument enabling the user to parse the argument by its own.
> Now to the semantic checking: I don't know if we should try to make the semantic checking declarative at all. It is of course possible to check the proper number of arguments, but whether an expression has to be an ICE or the proper type (see e.g. IBOutletCollection) should be checked in handler functions.

We'd like to be able to express some simple constraints declaratively (e.g., "only a function attribute"), but in general, I agree with you: we need some way to specify an arbitrary expression or handler function to determine whether the semantic constraints of the attribute are met.

> OK. I haven't talked about the current implementation yet. To make it short: I don't like it. Not at all. In fact it is the reason for my delayed response. I have digged into code and tried to understand what's going on. It took a while. All the semantic checking is in SemaDeclAttr but IMHO needs to be better tied to the attributes (there is also an appropriate comment in SemaDeclAttr.cpp). Then the Attr factory is the AttributeList. But it looks to me like it mirrors the attribute kinds generated from Attr.td.

Right, this stuff is a mess. Sean's GSoC project last year cleaned up some of the mess---Attr.td is now used to generate the attribute classes and their serialization/deserialization---but didn't get as far as fixing parsing or semantic analysis. The current scheme should be completely replaced with something generated via tblgen.

> Couldn't we stuff all this together? So that for each attribute we get a subclass of Attr holding the data (like now) and in addition a factory object which knows about the syntax and semantic of the attribute arguments. Then we can use tblgen to create the Attr taxonomy and the factories in one step. And of course we would provide an option for ASTConsumer to register own Attr factories.


Yes, and I see these as two separate steps: (1) using tblgen to generate the parsing and semantic analysis bits for all of the attributes, and (2) extending the plugin architecture to support the addition of attributes.

	- Doug