This is a CXXConstructExpr, so create a local temporary variable and initialize it.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/test/AST/Interp/records.cpp | ||
---|---|---|
314–315 | Nit: nothing actually tests that this object is destroyed correctly. Here's an interesting test to consider: struct S { constexpr S() {} constexpr ~S() noexcept(false) { throw 12; } }; constexpr int f() { S{}; return 12; } static_assert(f() == 12); That should fail because ~S() would hit the throw expression and thus is not valid. Note, you'll need to add -Wno-invalid-constexpr to your test to avoid the warning-defaults-to-error about the destructor never producing a constant expression. |
clang/test/AST/Interp/records.cpp | ||
---|---|---|
314–315 | There are multiple reasons why that sample is not rejected right now, one I can easily fix in a follow-up patch, the other one would actually require us to recognize the throw and reject it with a proper diagnostic. |
clang/test/AST/Interp/records.cpp | ||
---|---|---|
314–315 | We should definitely fix the throw at some point, but any of the dynamically reachable problematic constructs would work (dynamic_cast whose type would throw, invocation of the va_arg macro, reinterpret_cast, etc) |
clang/test/AST/Interp/records.cpp | ||
---|---|---|
314–315 | Yes, I think we need a new opcode for that so we only emit the diagnostic when such a construct is actually executed. |
clang/test/AST/Interp/records.cpp | ||
---|---|---|
314–315 | Oh yeah, you'll definitely need that, a whole pile of the constexpr rules are based around code reachability. Are you saying you've got no way to test this until you implement that opcode? |
clang/test/AST/Interp/records.cpp | ||
---|---|---|
314–315 | With https://reviews.llvm.org/D150040 applied, it gets properly rejected, just the diagnostics are off. I can add the test and reorder the commits. |
LG pending test coverage being ready to land
clang/test/AST/Interp/records.cpp | ||
---|---|---|
314–315 | SGTM, thanks! |
Nit: nothing actually tests that this object is destroyed correctly. Here's an interesting test to consider:
That should fail because ~S() would hit the throw expression and thus is not valid. Note, you'll need to add -Wno-invalid-constexpr to your test to avoid the warning-defaults-to-error about the destructor never producing a constant expression.