C++ new expression

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?

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?

Thanks,
Sebastian

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

I've thought about it, but would it correctly handle the expression list?
Wouldn'it it parse it as a comma expression?

Guess I'll have to take a closer look at the code; if nothing else, I can
probably use it as a guideline for implementing my own stuff.

Sebastian

Yeah, you'll probably need to implement something like
ParseParenExpression that actually parses an expression-list inside
the parens.

  - Doug

OK, here's my patch for initial parsing, AST and Sema support. There's still some shortcomings, but I'd like to check it in as is, and enhance it later.

Shortcomings:
1) Doesn't parse ::new and ::delete
2) Doesn't correctly handle new (type[10]), because the expression is lost.
3) AST printing is incomplete.
4) Doesn't look for an appropriate operator new overload.
5) Doesn't look for an appropriate constructor.

In other words, the sema is very incomplete.

Doug, I could use some help with the overloading.

Sebastian

new-delete.patch (37.5 KB)

Sebastian Redl wrote:

OK, here's my patch for initial parsing, AST and Sema support. There's still some shortcomings, but I'd like to check it in as is, and enhance it later.

Ignore this patch, it's out of date. I've got a new one, but there's still a bug there, and I have a headache so I can't find it now.

Sebastian

Sebastian Redl wrote:

Sebastian Redl wrote:
  

OK, here's my patch for initial parsing, AST and Sema support. There's still some shortcomings, but I'd like to check it in as is, and enhance it later.
    

Ignore this patch, it's out of date. I've got a new one, but there's still a bug there, and I have a headache so I can't find it now.
  

Ah, finally.

This one is pretty good. Still doesn't have all the checking I want, but it selects a constructor. For more checking, I'll have to study Doug's work on names.

Sebastian

new-delete.patch (47.8 KB)