[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.
John.
More information about the cfe-dev
mailing list