[cfe-dev] parsing code snippets

[Douglas Gregor]

Sent from my iPhone

On May 6, 2011, at 8:46 AM, Olaf Krzikalla <Olaf.Krzikalla at tu-dresden.de> wrote:

> Am 06.05.2011 16:12, schrieb Douglas Gregor:
>> To put this into the open-source tree, I'd want some evidence that this is the right way to support the kind of extensibility you're looking for. I think there's probably a better way.
> Yep, I'm unsure about the proper approach either...
> 
>>> 2. How can we expose the current parser obejct to custom handlers
>>> (attribute or pragma)?
>> 
>> I don't have a good answer. For attributes, the idea was that we would have a way to describe the grammar of the attribute (with a *very* restrictive syntax), and have tblgen generate the attribute parsers from that. But, as far as I know, nobody is working on this at the moment.
> ... but maybe we can tie and handle both issues together.
> I wouldn't mind about the handling of expressions inside pragmas (which actually is part of the preprocessor!) if I have the freedom to handle them in attribute lists. And if nobody is working an that issue and I need it, then... well, I will be the one (I hesitated mainly because actually Sean Hunt had worked on that issue and there is already some handling of C0xx attributes in clang at various locations).

I don't know if Sean intends to continue this work. Hopefully, he'll chime in one way or the other. 

> I'm sure, attributes were initially and still are intendend for the use with expressions (N2418 clearly mentions expressions and
> according to the draft n3242 the grammar for arguments is broadened even further).

Yes. 

> That said, IMHO we need
> 1. a callback mechanism for attributes similiar to the PragmaHandler (I would restrict customization to scoped attributes and use the scope name similiar tho the pragma ns).

This is actually different from the way I was planning to go. The intent for attributes was to describe the grammar in the .td file, rather than calling out to a separately-registered handler. I'm open to both options, of course. 

> 2. a map from Stmts to Attrs in the ASTContext similiar to DeclAttrs.

Right, we need this and Sema code to check the attributes added to statements and expressions. 

> 3. an attr::Kind "UserDefined" and an appropriate Attr subclass.
> 4. means in the attribute handler in order to conveniently parse attribute arguments.

Interesting. Do we need dynamic registration of handlers? That's a big step beyond just making it easy to add new attributes. 

> I think that we can reach an agreement about approaches for pt.1-3 rather quickly.
> For pt.4 my first idea would be an attribute handler which has some (protected) functions which supports the parsing of argument lists.
> Or we pass the parser as an argument to the handler function (like it is done with the preprocessor in the pragma handler) but then we have to publish the parser interface.
> Of course the other way is a somewhat declarative interface. However I don't know how to design it open and extensible. Is there any preliminary work in that direction?
> 
> 
> Best regards
> Olaf Krzikalla
> 
> 
> The fine print: If I work on attributes, I want a bit in LangOptions in order to enable attributes beyond C++0x :-)