[clang++] Error when inspect the common initial sequence of standard-layout structs of the union

[safocl]

Code

consteval void foo(){
    union { struct {int i1; int i2; int i3; int i4;} s;
            struct {int i1; int i2; int i3; int i4;} s2;
            int i[4];
    } u{};
                
    auto sum = u.s2.i1+u.s2.i1+u.s2.i1+u.s2.i1;
}

int main(){
    foo();
}

produces error with

note: read of member 's2' of union with active member 's' is not allowed in a constant expression
    7 |     auto sum = u.s2.i1+u.s2.i1+u.s2.i1+u.s2.i1;
      |                ^

https://godbolt.org/z/dcPWW8ncx
(this tested from clang-x86_64 10.0.0 to clang-x86_64 20.1.0 and trunk version on godbolt)

but:
https://eel.is/c++draft/class.union#general-note-1
https://eel.is/c++draft/class.mem#general-27
https://eel.is/c++draft/class.prop#10
https://eel.is/c++draft/class.mem#def:layout-compatible,class
https://eel.is/c++draft/class.mem#general-29

the s and s2 union members are two standard-layout struct types and have common initial sequence (and what's more: they are layout-compatible).

in my opinion the error behavior here is a bug.

[safocl]

and this example is alarming, because it is not clear what to expect from the runtime for similar code - will there be undefined behavior, or will the behavior be defined?

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (safocl)

Code ```cpp consteval void foo(){ union { struct {int i1; int i2; int i3; int i4;} s; struct {int i1; int i2; int i3; int i4;} s2; int i[4]; } u{};

auto sum = u.s2.i1+u.s2.i1+u.s2.i1+u.s2.i1;

}

int main(){
foo();
}

produces error with 

note: read of member 's2' of union with active member 's' is not allowed in a constant expression
7 | auto sum = u.s2.i1+u.s2.i1+u.s2.i1+u.s2.i1;
| ^

https://godbolt.org/z/dcPWW8ncx
(this tested from clang-x86_64 10.0.0 to clang-x86_64 20.1.0 and trunk version on godbolt)

but:
https://eel.is/c++draft/class.union#general-note-1
https://eel.is/c++draft/class.mem#general-27
https://eel.is/c++draft/class.prop#<!-- -->10
https://eel.is/c++draft/class.mem#def:layout-compatible,class
https://eel.is/c++draft/class.mem#general-29

the `s` and `s2` union members are two standard-layout struct types and have common initial sequence (and what's more: they are layout-compatible).

in my opinion the error behavior here is a bug.
</details>

[shafik]

Constant expression do not allow the access of inactive members, regardless whether they are part of the common initial sequence or not: expr.const p2:

... other than inactive union members ...

Note implementation are consistent here: https://godbolt.org/z/Yzqa691v1

[safocl]

Constant expression do not allow the access of inactive members, regardless whether they are part of the common initial sequence or not: expr.const p2:

... other than inactive union members ...

Note implementation are consistent here: https://godbolt.org/z/Yzqa691v1

could you please clarify whether these changes in the definition of constant expression are backported to the c++17, c++20, c++23 standards? Since I do not see such text in the specified drafts of these standards:
с++23 n4950 (expr.const)
с++20 n4861 (expr.const)
с++17 n4659 (expr.const)

and these requirements are implemented in your compiler for standards c++17, c++20, c++23?

[shafik]

Constant expression do not allow the access of inactive members, regardless whether they are part of the common initial sequence or not: expr.const p2:

... other than inactive union members ...

Note implementation are consistent here: https://godbolt.org/z/Yzqa691v1

could you please clarify whether these changes in the definition of constant expression are backported to the c++17, c++20, c++23 standards. Since I do not see such text in the specified drafts of these standards: с++23 n4950 с++20 n4861 с++17 n4659

and these requirements are implemented in your compiler for standards c++17, c++20, c++23?

This has always been the case, the wording has just moved around and morphed a bit, which is not ideal but unfortunately sometimes needed to clarify for core issues or new proposals:

https://timsong-cpp.github.io/cppwp/n4950/expr.const#5.10

[safocl]

Constant expression do not allow the access of inactive members, regardless whether they are part of the common initial sequence or not: expr.const p2:

... other than inactive union members ...

Note implementation are consistent here: https://godbolt.org/z/Yzqa691v1

and one more suggestion (question) -- shouldn't this particular rule for the common initial sequence apply to constant-expression as well, since the standard states "the behavior is as if the corresponding member of T1 were nominated." (https://eel.is/c++draft/class.mem#general-29.sentence-1)?

in other words -- shouldn't constant-expression treat it as if the active member was nominated in such a case?

[frederick-vs-ja]

Source for the restriction in existing standard revisions since C++11:

• C++11 N3337 [expr.const]/2.10
• C++14 N4140 [expr.const]/2.8
• C++17 N4659 [expr.const]/2.8
• C++20 N4868 [expr.const]/5.9
• C++23 N4950 [expr.const]/5.10

and one more suggestion (question) -- shouldn't this particular rule for the common initial sequence apply to constant-expression as well, since the standard states "the behavior is as if the corresponding member of T1 were nominated." (https://eel.is/c++draft/class.mem#general-29.sentence-1)?

in other words -- shouldn't constant-expression treat it as if the active member was nominated in such a case?

This is a design change (which doesn't seem a defect report to me) and thus needs a WG21 paper. At the first glance, I think this is feasible. But implementors may have different opinions.

[shafik]

This is a design change (which doesn't seem a defect report to me) and thus needs a WG21 paper. At the first glance, I think this is feasible. But implementors may have different opinions.

There was p0120r0 but it was rejected in Kona. I don't see a rationale for why though. Maybe someone could reach out to the author.

[safocl]

Thank you very much for the extensive explanations, at the moment I have decided that this is how the provisions of the standard should be perceived (until the introduction of an explicit indication in the [expr.const] section about the possibility of access to the common initial sequence through an inactive member of the union).