[cfe-dev] C++ new expression

[Eli Friedman]

On Wed, Nov 12, 2008 at 3:06 PM, Sebastian Redl
<sebastian.redl at getdesigned.at> wrote:
> Hi,
>
> I'm currently implementing parsing new and delete, and I need a bit of help.
> The grammar of new-expression means that at one point, I have to
> distinguish between
>
> '(' expression-list ')' # new-placement
> and
> '(' type-id ')' # alternate form of specifying the type
>
> type-id is a normal C++ type-id, like it appears in cast expressions.
> expression-list is an argument list as it appears in function calls.
>
> Is there anything already in the parser that helps me disambiguate
> between the two?

ParseParenExpression should work, I think.

> Also, the prototype of the Action callback for the new expression now
> looks like this:
>
>  virtual ExprResult ActOnCXXNew(SourceLocation StartLoc, bool UseGlobal,
>                                 SourceLocation PlacementLParen,
>                                 ExprTy **PlacementArgs, unsigned
> NumPlaceArgs,
>                                 SourceLocation PlacementRParen,
>                                 SourceLocation TyStart, TypeTy *Ty,
>                                 ExprTy **ArraySizes, unsigned NumDims,
>                                 SourceLocation TyEnd,
>                                 SourceLocation ConstructorLParen,
>                                 ExprTy **ConstructorArgs, unsigned
> NumConsArgs,
>                                 SourceLocation ConstructorRParen) {
>
> StartLoc is the start of the entire expression
> UseGlobal indicates whether ::new was used
> Placement* are the placement new arguments
> Ty* and ArraySizes/NumDims are for the actual type of the allocation
> (this feels wrong, somehow)
> Constructor* are for the constructor arguments
>
> This is awfully large. Do you have any ideas how to better structure
> this information?

Nope, no better suggestions; I think it's just fundamentally
complicated.  Although, there is at most one non-constant array
dimension; you could simplify slightly in that direction at the
expense of making the parser code a bit more complicated.

-Eli