[Clang] constant evaluator thinks that elements of an unnamed struct is not initialized

[philnik777]

struct T {
  int i;
};

struct S {
  struct {
    T val;
  };

  constexpr S() : val() {}
  constexpr ~S() {}

  constexpr T get() { return val; }
};

constexpr bool func() {
  S s;
  return s.get().i == 0;
}

static_assert(func());

Here Clang says that val isn't initialized, even though it pretty clearly is.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Nikolas Klauser (philnik777)

``` struct T { int i; };

struct S {
struct {
T val;
};

constexpr S() : val() {}
constexpr ~S() {}

constexpr T get() { return val; }
};

constexpr bool func() {
S s;
return s.get().i == 0;
}

static_assert(func());

Here Clang says that `val` isn't initialized, even though it pretty clearly is.
</details>

[shafik]

I think we are not fully implementing CWG2859 although interesting enough the initial report does not point out this difference, it made it sound we all do the same thing here: cplusplus/CWG#501

[tbaederr]

Seems to be about the anonymous union: https://godbolt.org/z/Ejrc4hrx8

[efriedma-quic]

Specifically

llvm-project/clang/lib/AST/ExprConstant.cpp

Line 6887 in 691ccf2

// FIXME: This immediately starts the lifetime of all members of

. Initializing the struct like that apparently confuses the RecordExprEvaluator::VisitCXXConstructExpr.

[tbaederr]

I think this is more the comment right before:

        // FIXME: In this case, the values of the other subobjects are
        // specified, since zero-initialization sets all padding bits to zero.

We then call `handleDefaultInitValue, which doesn't initialize primitive fields, only records and arrays. Which leaves us with:

Struct
`-field: Struct
  `-field: Struct
    `-field: Indeterminate

[tbaederr]

... and since the anonymous union now has a value (even if one field is left indeterminate), we ignore it in RecordExprEvaluator::VisitCXXConstructExpr().

[ldionne]

FWIW I believe this may block us from implementing a fix for an ABI break reported in #154146 without breaking std::unique_ptr constant evaluation. I think it would be very very valuable to fix this ASAP. Thanks a lot for having a look already!

[efriedma-quic]

FWIW I believe this may block us from implementing a fix for an ABI break reported in #154146 without breaking std::unique_ptr constant evaluation.

This should only trigger if you write exactly S() : val() to initialize a member of an anonymous struct that's an aggregate class. S() : val(T()) is fine, using an in-class initializer is fine. I would be surprised if you can't work around this, although I'm not sure what exactly your constraints are here.

[philnik777]

FWIW I believe this may block us from implementing a fix for an ABI break reported in #154146 without breaking std::unique_ptr constant evaluation.

This should only trigger if you write exactly S() : val() to initialize a member of an anonymous struct that's an aggregate class. S() : val(T()) is fine, using an in-class initializer is fine. I would be surprised if you can't work around this, although I'm not sure what exactly your constraints are here.

I've tried that already, but AFAICT that doesn't work: https://godbolt.org/z/4Ke8ox8Yx. It kinda worked for string, but there I initialize it slightly differently, which does indeed work around the problem. The same isn't possible for unique_ptr though.