[Clang][CodeGen] Investigate possible missed case for trivial ctor constant handling

[andykaylor]

There is a case in ConstantExprEmitter::VisitCXXConstructExpr where we are handling trivial constructor calls with arguments, and if the argument expression is not a MaterializeTemporaryExpr we just return nullptr (meaning we don't emit a constant here). There is a comment that says "Don't try to support arbitrary lvalue-to-rvalue conversions for now." but when reviewing this code for the CIR-equivalent handling (#164849), @erichkeane raised concerns that this didn't seem right.

There are around a dozen places in the clang/CodeGenCXX tests where the dyn_cast to MaterializeTemporaryExpr fails, but none of them appear to be constant. I haven't been able to create a case that hits this location with a constant, but I'm not certain that it isn't possible. Even if it does happen, there's a chance that we'd generate the correct code somewhere else.

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: Andy Kaylor (andykaylor)

There is a case in `ConstantExprEmitter::VisitCXXConstructExpr` where we are handling trivial constructor calls with arguments, and if the argument expression is not a `MaterializeTemporaryExpr` we just return nullptr (meaning we don't emit a constant here). There is a comment that says "Don't try to support arbitrary lvalue-to-rvalue conversions for now." but when reviewing this code for the CIR-equivalent handling (https://github.com//pull/164849), @erichkeane raised concerns that this didn't seem right.

There are around a dozen places in the clang/CodeGenCXX tests where the dyn_cast to MaterializeTemporaryExpr fails, but none of them appear to be constant. I haven't been able to create a case that hits this location with a constant, but I'm not certain that it isn't possible. Even if it does happen, there's a chance that we'd generate the correct code somewhere else.