[cfe-dev] ParseFunctionDeclarator

[John McCall]

On Jun 25, 2011, at 5:27 AM, Sebastian Redl wrote:

> 
> On 24.06.2011, at 23:14, John Freeman wrote:
> 
>> The documentation for Parser::ParseFunctionDeclarator (hereafter 
>> referred to as PFD) has this note near the end:
>> 
>>  For C++, after the parameter-list, it also parses "cv-qualifier-
>>  seq[opt]", C++0x "ref-qualifier[opt]" and "exception-
>>  specification[opt]".
>> 
>> I would like to use this function when parsing lambda expressions, but 
>> the extra parts it parses at the end are simultaneously too much 
>> (cv-qualifier-seq, ref-qualifier) and not enough (attribute-specifier, 
>> 'mutable') for lambdas.
> 
> You have several options. Making ParseFunctionDeclarator parse lambdas and have every existing client check for unexpected pieces is probably the worst.
> Splitting ParseFunctionDeclarator into component parts so that you can reuse them is a pretty good option.
> Another option is to simply pass a boolean to ParseFunctionDeclarator that tells it to continue lambda-style after the parameters instead of function-style. Default it to false and you might not even have to change the code for all other uses, but in any case the compiler will tell you if you do it wrong. We do stuff like this a lot.
> Of course, a boolean gives two complicated branches. Yet another option would be to pass the "after-parameters" action as a function pointer. Basically, you factor the existing cv-qualifier etc. parsing stuff as well as the AddTypeInfo call into a function and make every existing call site pass that, while your lambda parser stuff passes a different function that parses mutable and attributes and calls the appropriate AddTypeInfo variant. ParseCXXNewExpresssion does something similar for ParseDeclarator.
> 
> The choice is yours.

Declarators already have a context, indicating where they were written, and we'll need a new setting for lambda declarators anyway.  It's possible that that can be harnessed, i.e. if we're parsing a lambda declarator and this is the 'right-most' function chunk.

John.