Invalid consteval constructor invocation does not cause an error

[stbergmann]

Bugzilla Link	52251
Version	trunk
OS	Linux
CC	@AaronBallman,@zygoloid

Extended Description

At least with Clang 13 and recent Clang 14 trunk,

$ cat test.cc
struct S {
consteval S() {}
int a;
};
S s2;

$ clang++ -std=c++20 -fsyntax-only test.cc

erroneously succeeds, while e.g. with GCC 11 it fails with

$ g++ -std=c++20 -fsyntax-only test.cc
test.cc:5:3: error: ‘S()’ is not a constant expression
5 | S s2;
| ^~
test.cc:5:3: error: ‘s2.S::S()’ is not a constant expression because it refers to an incompletely initialized variable

(I think this is different from bug 51560, as the initialization of s2 here asks for default-initialization via the S() constructor.)

[AaronBallman]

This is an issue. We currently fail to check immediate invocations of constructors in other interesting ways as well:

template <typename Ty>
struct S {
  consteval S() = default;
  Ty Val;
};

struct foo {
  foo();
};

S<int> s1; // Correctly accepted
S<foo> s2; // Incorrectly accepted

[llvmbot]

@llvm/issue-subscribers-c-20

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[AaronBallman]

I've been looking into this issue pretty deeply lately and have some new thoughts.

struct S {
  consteval S() {}
  int a;
};
S s2;

After the adoption of P1331R2 in C++20, this code becomes valid because static initialization kicks in before constant evaluation does, so s2 has its members initialized per http://eel.is/c++draft/basic.start.static#1, https://eel.is/c++draft/basic.start.static#2.sentence-2, and http://eel.is/c++draft/dcl.init#general-6.2. So I think GCC is incorrect to diagnose that code and Clang is correct to accept it.

However, the example I gave in my comment is still code that should not be accepted in the S<foo> case because that calls a constructor which is not constant evaluatable (foo::foo()).

[AaronBallman]

That said, I think the fix for the second case will end up breaking the first case so that we wind up diagnosing in Clang the same as GCC, ICC, and MSCV all currently diagnose. One of the problems we have is that we do not add an expression evaluation context for the translation unit itself, so we don't issue any constant expression diagnostics for globals currently. Another problem is that we don't seem to model static initialization as being zero initialization in the constant expression evaluator, and so we consider the members of a statically initialized structure as being uninitialized.

[AaronBallman]

1c55f05 addresses part of the issues here.