[all-commits] [llvm/llvm-project] c448ea: [libc++] Fix for the Bug 41784

[Ruslan Arutyunyan via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: c448ea948c28878735fefec734d8326ca2e4b33a
      https://github.com/llvm/llvm-project/commit/c448ea948c28878735fefec734d8326ca2e4b33a
  Author: Ruslan Arutyunyan <ruslan.arutyunyan at intel.com>
  Date:   2021-02-01 (Mon, 01 Feb 2021)

  Changed paths:
    M libcxx/include/atomic
    A libcxx/test/std/atomics/atomics.types.generic/copy_semantics_traits.pass.cpp
    A libcxx/test/std/atomics/atomics.types.operations/atomics.types.operations.req/copy.assign.ptr.volatile.verify.cpp
    A libcxx/test/std/atomics/atomics.types.operations/atomics.types.operations.req/copy.assign.volatile.verify.cpp

  Log Message:
  -----------
  [libc++] Fix for the Bug 41784

Add deleted volatile copy-assignment operator in the most derived atomic
to fix the Bug 41784. The root cause: there is an `operator=(T) volatile`
that has better match than the deleted copy-assignment operator of the base
class when `this` is `volatile`. The compiler sees that right operand of
the assignment operator can be converted to `T` and chooses that path
without taking into account the deleted copy-assignment operator of the
base class.

The current behavior on libstdc++ is different from what we have in libc++.
On the same test compilation fails with libstdc++. Proof: https://godbolt.org/z/nebPYd
(everything is the same except the -stdlib option).

I choose the way with explicit definition of copy-assignment for atomic
in the most derived class. But probably we can fix that by moving
`operator=(T)` overloads to the base class from both specializations.
At first glance, it shouldn't break anything.

Differential Revision: https://reviews.llvm.org/D90968