[cfe-dev] Strange AST behavior with C++ casts

John McCall rjmccall at apple.com
Mon Oct 3 10:37:10 PDT 2011

On Oct 3, 2011, at 10:17 AM, Nicola Gigante wrote:
> This function tries to see if a static cast is applicable, and to do so, builds an initialization sequence that when performed creates the wrong ImplicitCastExpr node. It generally works as expected because,
> as pointed out by a nearby comment, a static_cast of expression e to type T can be
> done if "T t(e);" is well-formed. However, I think the initialization shouldn't really be performed
> as if that code had really been written. At this point, InitializationSequence::Perform() should
> have been told that it's an explicit cast.

It has been;  it's part of the InitializedEntity.

> So, to recap:
> - Have I understood correctly why this issue happens?

Well, it's not accidental.  C's semantics are easy enough to check with a function that, logically, just computes a cast kind for the conversion, adding extra implicit casts in the rare cases where they're required.  C++'s semantics aren't that simple;  we can generate a lot of expressions for one of those casts, and the outermost node is not always a cast at all.

> - Is it ok if I try to fix it? i.e. will this change in the AST cause problems in other parts of the compiler? (in this case, I would also fix them of course)

> - Any suggestions to how to fix the issue?

Well, you could teach the explicit cast code to strip off an outermost ImplicitCastExpr and use its semantics for the ExplicitCastExpr;  that would generate tidier ASTs in some common cases.  It still won't stop your code from potentially needing to handle arbitrary stuff "implementing" a NoOp explicit cast, though.


More information about the cfe-dev mailing list