[clang] Immediate invocations in constexpr initailizers are evaluated twice

[groundswellaudio]

It seems that immediate invocations in constexpr initailizers are evaluated twice, once on evaluating the decl, and again on Sema::HandleImmediateInvocations (this doesn't happen if the var is within a consteval function). Strictly speaking, not a defect, but it's kinda wasteful?

consteval int foo(int* b) {
    return *b; // Evaluation errors are emitted twice
}

constexpr int a = foo(nullptr); 

https://godbolt.org/z/7ec5bsK9e

[AaronBallman]

Correct; we evaluate constant expressions multiple times in quite a few cases and I think we should be caching the results more aggressively.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (groundswellaudio)

It seems that immediate invocations in constexpr initailizers are evaluated twice, once on evaluating the decl, and again on Sema::HandleImmediateInvocations (this doesn't happen if the var is within a consteval function). Strictly speaking, not a defect, but it's kinda wasteful?

consteval int foo(int* b) {
    return *b; // Evaluation errors are emitted twice
}

constexpr int a = foo(nullptr); 

https://godbolt.org/z/7ec5bsK9e

[groundswellaudio]

I think it might be possible to not add to the ImmediateInvocations set while in the initialiser of a constexpr variable.

[efriedma-quic]

In some cases, the "evaluate twice" semantics are required by the standard, and I'd rather keep the parsing as unified as possible. See also #89565. (Note the semantics are slightly different in C++23 mode.)

Probably the answer here is to just tweak the way error recovery works: we should treat initializers for constexpr variables as an immediate function context even if evaluation produces an error, so we don't get redundant error messages.