[PATCH] D127593: [clang] Fix trivially copyable for copy constructor and copy assignment operator

Stephan Bergmann via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Jun 20 14:17:10 PDT 2022

sberg added a comment.

In D127593#3596883 <https://reviews.llvm.org/D127593#3596883>, @royjacobson wrote:

> In D127593#3596601 <https://reviews.llvm.org/D127593#3596601>, @sberg wrote:
>> Is it intended that a deleted copy assignment op as in `struct S { void operator =(S &) = delete; };` (though, somewhat oddly, not in `struct S { void operator =(S) = delete; };`) is now marked as trivial?
>> I think that's the root cause why a build of PDFium with clang-cl against the MSVC standard library started to fail for me now, effectively complaining that `__is_trivially_assignable(std::pair<int,int> &, std::pair<int,int> const &)` is false (as expected) while `__has_trivial_assign(std::pair<int,int>)` is (unexpectedly) true.
> I don't see it on godbolt trunk: https://godbolt.org/z/KPfxWqnhd.

You'd only see it when compiling with Clang against MSVC's `<utility>`, where `std::pair` has a deleted copy assignment op (something I approximated with the `struct S` above).  https://godbolt.org/z/bbEqvosvP shows how the behavior changed in Clang trunk. (Interestingly, the behavior is different between MSVC and GCC, and Clang now changed from matching the MSVC behavior to matching the GCC one.)

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list