[cfe-dev] AST representation for parentheses inside types.

[Enea Zaffanella]

Il 07/12/2010 18:36, Douglas Gregor ha scritto:
> 
> On Dec 7, 2010, at 6:39 AM, Enea Zaffanella wrote:
> 
>> Hello.
>>
>> We noticed some time ago that the AST representation used in clang does
>> not allow for the representation of those pairs of parentheses that can
>> occur inside a syntactic type. For instance, the following C code:
>>
>> void ((((*fun_ptr))))(void);
>> int (*(int_arr_ptr))[15];
>> void (((*((*fun_ptr_arr_ptr)[10]))))(int, int);
>> int ((a));
>>
>> is printed (using -ast-print) as follows
>>
>> void (*fun_ptr)(void);
>> int (*int_arr_ptr)[15];
>> void (*(*fun_ptr_arr_ptr)[10])(int, int);
>> int a;
>>
>> The printed parentheses are not directly represented in the AST: they
>> are inserted by the pretty printer (to respect precedence).
>>
>> Are there plans to extend the AST in order to faithfully represent the
>> code above?
> 
> Not that I know of.
> 
>> To our eyes, it seems that the Type hierarchy should be enriched by
>> adding a ParenType derived class (similar to the ParenExpr class for the
>> Expr hierarchy). A ParenType would always be a non-canonical type and
>> the corresponding ParenTypeLoc would provide locations for the two
>> parentheses. At the parser level, we would have another kind of
>> DeclaratorChunk.
>>
>> Would this approach make sense?
> 
> Yes, this approach makes sense to me.
> 
> 	- Doug

OK, here is attached a patch along the sketch mentioned above.
It passes all clang tests but a single one.

The failing test is something related to ObjC, on which I have very
little confidence. Apparently, it seems that we should adjust the
expected output, which currently is as follows:

FunctionDecl:{ResultType void}{TypedText f}{LeftParen (}{Placeholder
^int(int x, int y)block}{RightParen )} (50)

whereas we now obtain an extra pair of parentheses:

FunctionDecl:{ResultType void}{TypedText f}{LeftParen (}{Placeholder int
(^)(int, int)}{RightParen )} (50)

We look forward for suggestions/corrections/etc.

Enea.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ParenType.patch
Type: text/x-patch
Size: 33645 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101208/02c86296/attachment.bin>