[llvm-bugs] [Bug 51260] New: Incomplete implementation of the P1330R0 proposal / [expr.const]p5 and [class.union]p6 (N4892)

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=51260

            Bug ID: 51260
           Summary: Incomplete implementation of the P1330R0 proposal /
                    [expr.const]p5 and [class.union]p6 (N4892)
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: matthewjbarichello at gmail.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

Created attachment 25087
  --> https://bugs.llvm.org/attachment.cgi?id=25087&action=edit
Patch to fix the issue in 'releases/12.x'

All of the references and quotes in this report are concerned with the changes
in P1330R0 and the current working standard document, N4892:
 - P1330R0: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1330r0.pdf
 - N4892:   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/n4892.pdf

Affected versions:
 - trunk
 - 12.0.1
 - 12.0.0
 - 11.0.1
 - 11.0.0
 - 10.0.1
 - 10.0.0
 - 9.0.1
 - 9.0.0

Driver cmdline:
Note: For versions not supporting -std=c++20, -std=c++2a was used.
 clang++ -std=c++20

Consider the following examples:
 [Example A:
  struct A {};

  constexpr auto test() {
   union U {
    int i;
    A a;
   } u{.i = 0};
   u.a = {};
   return 0;
  }

  int main() {
   constexpr auto r = test();
   (void)r;
  }

 [Example B:
  struct A {
   int i;

   constexpr A() noexcept : i(0) {}
   constexpr A(int i) noexcept : i(i) {}

   constexpr A& operator=(A const& other) noexcept {
    i = other.i;
    return *this;
   }
  };

  constexpr auto test() {
   union U {
    int i;
    A a;
   } u{.i = 0};
   u.a = {123};
   return u.a.i;
  }

  int main() {
   constexpr auto r = test();
   (void)r;
  }

 According to [expr.constant]p5

  An expression E is a core constant expression unless the evaluation of E,
following the rules of the abstract machine (6.9.1), would evaluate one of the
following:
   ... an invocation of an implicitly-defined copy/move constructor or
copy/move assignment operator for a union whose active member (if any) is
mutable, unless the lifetime of the union object began within the evaluation of
E ...

 , and [class.union]p6

  When the left operand of an assignment operator involves a member access
expression (7.6.1.5) that nominates a union member, it may begin the lifetime
of that union member ...

 , the lifetime of `u.a` ("Example A":8) should start at the invocation of
`A`'s implicitly defined copy-assignment operator, however, under all listed
clang versions this is not the case as compilation yields the following error:

  "Example A":13:17: error: constexpr variable 'r' must be initialized by a
constant expression
  constexpr auto r = test();
                 ^   ~~~~~~
  "Example A":8:6: note: member call on member 'a' of union with active member
'i' is not allowed in a constant expression
  u.a = {};
      ^
  "Example A":13:21: note: in call to 'test()'
  constexpr auto r = test();
                     ^
  1 error generated.

 Likewise, the lifetime of `u.a` ("Example B":18) should begin at the
invocation of `A`'s user-defined constexpr copy-assignment operator, however
compilation yields the same error.

Addressing the issue:
 I plan to formally submit a properly tested patch to trunk and backport it to
all affected major clang releases. Until then, I've attached a patch to address
this bug, based on the `release/12.x` tag:

  commit fed41342a82f5a3a9201819a82bf7a48313e296b (grafted, HEAD ->
release/12.x, tag: llvmorg-12.0.1-rc4, tag: llvmorg-12.0.1,
origin/release/12.x)
  Author: Tom Stellard <tstellar at redhat.com>
  Date:   Mon Jun 28 09:23:38 2021 -0700

      Revert "Revert "[Coverage] Fix branch coverage merging in
FunctionCoverageSummary::get() for instantiation""

      This reverts commit 33d312b2d731507327252fd597bac1b738870330.

      The original patch was correct, so we need to restore it in the
      release branch.

Notes:
 - In testing both examples against other major compilers, such as MSVC and
GCC, it would seem that they compile and behave as expected.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210729/0e2ffc57/attachment-0001.html>