Destroying an object during a call to construct_at erroneously rejected during constant evaluation

[davidstone]

The following valid (I think) translation unit

#include <memory>

struct ref_holder {
	constexpr explicit ref_holder(int & value):
		m_value(value)
	{
	}

	constexpr operator int() const {
		using T = int;
		m_value.~T();
		return int();
	}

private:
	int & m_value;
};

constexpr bool f() {
	int x = 0;
	std::construct_at(&x, ref_holder(x));
	return true;
}

static_assert(f());

is rejected by clang with

<source>:25:15: error: static assertion expression is not an integral constant expression
static_assert(f());
              ^~~
<source>:11:3: note: destruction of object outside its lifetime is not allowed in a constant expression
                m_value.~T();
                ^
/opt/compiler-explorer/clang-assertions-trunk-20230319/bin/../include/c++/v1/__memory/construct_at.h:38:50: note: in call to '&ref_holder(x)->operator int()'
  return ::new (std::__voidify(*__location)) _Tp(std::forward<_Args>(__args)...);
                                                 ^
<source>:21:2: note: in call to 'construct_at(&x, ref_holder(x))'
        std::construct_at(&x, ref_holder(x));
        ^
<source>:25:15: note: in call to 'f()'
static_assert(f());
              ^
1 error generated.
Compiler returned: 1

See it live: https://godbolt.org/z/T6Wo6rd6d

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[shafik]

I am wondering if this is not working b/c we don't support P2280R4: Using unknown pointers and references in constant expressions.

Looking at the code that this is failing at, I don't see anything obviously off:

 // Walk the designator's path to find the subobject.
  for (unsigned I = 0, N = Sub.Entries.size(); /**/; ++I) {
    // Reading an indeterminate value is undefined, but assigning over one is OK.
    if ((O->isAbsent() && !(handler.AccessKind == AK_Construct && I == N)) ||
        (O->isIndeterminate() &&
         !isValidIndeterminateAccess(handler.AccessKind))) {
      if (!Info.checkingPotentialConstantExpression())
        Info.FFDiag(E, diag::note_constexpr_access_uninit)
            << handler.AccessKind << O->isIndeterminate();
      return handler.failed();
    }

CC @zygoloid

[zygoloid]

It looks like the problem is that we end the lifetime of the existing object before evaluating the initializer of the new object.

But... it's not obvious to me whether that's wrong. For example, in:

struct B { ... };
struct A {
  A(B x);
};
A a;
B f();
new (&a) A(f());

... what is the order of operations? Is it

• call operator new
• call f() to initialize B x parameter
• end lifetime of a
• call A constructor

or is it

• call operator new
• end lifetime of a
• call f() to initialize B x parameter
• call A constructor

? Usually we model a function call (including a constructor call) as an atomic operation for evaluation purposes -- we don't evaluate the arguments, then take some other action, then call the function. And there are very similar cases where we must have that kind of behavior:

struct B { ... };
struct A {
  B x;
};
A a;
B f();
new (&a) A(f());

Here, we must end the lifetime of a before we call f(), because f is going to directly initialize the member a.x in place.

So it seems to me that interpreting the "storage which the object occupies is reused" as happening the moment that operator new(...) returns it is the most consistent interpretation of the standard's wording, and under that model, Clang's behavior is correct.

[zygoloid]

Filed cplusplus/CWG#278 to get some CWG input on this question.

[zygoloid]

It looks like the implementation divergence here is because GCC and MSVC don't implement CWG2256 yet: https://godbolt.org/z/s5PnMGqnc

[davidstone]

Based on the resolution to CWG2721, the current behavior is correct.