[clang] [clang][Sema] Track trivial-relocatability as a type trait (PR #84621)

[Giuseppe D'Angelo via cfe-commits]

@@ -857,8 +881,13 @@ void CXXRecordDecl::addedMember(Decl *D) {
 data().HasDeclaredCopyAssignmentWithConstParam = true;
 }
 
-if (Method->isMoveAssignmentOperator())
+if (Method->isMoveAssignmentOperator()) {
   SMKind |= SMF_MoveAssignment;
+}
+
+if (Method->isUserProvided() &&
+(Method->isCopyAssignment() || Method->isMoveAssignment()))
+  data().IsNaturallyTriviallyRelocatable = false;

dangelog wrote:

I've also been asked to comment. My personal opinion is that relocability is 
strictly tied to the Rule Of Five. The moment a user decides to opt into the 
RO5 by e.g. writing a custom assignment operator, they should lose trivial 
relocability, unless they do something extra to gain it back (different 
proposals disagree on the syntax but ultimately they achieve the same). (We may 
then argue regarding all the subtleties about user-declared vs. user-defaulted 
vs. user-defined, but I don't really have a strong opinion about that.)

https://github.com/llvm/llvm-project/pull/84621
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Sema] Track trivial-relocatability as a type trait (PR #84621)

[Giuseppe D'Angelo via cfe-commits]

dangelog wrote:

I perfectly understand that Clang wants to implement the semantics that are 
being adopted by standard C++, so it wants to reserve 
`__is_trivially_relocatable` to match those semantics.

The amount of comments in this PR is however a strong signal that standard C++ 
is going directly against widely established practices. Qt won't need P2786 but 
P1144, because it uses trivial relocation not only ① for vector reallocation 
(that is: move *construction* + destruction via trivial relocation) but also ② 
for vector erase/insert (that is: move *assignment* (+destruction) via trivial 
relocation). It would not make sense for a type with a user-declared assignment 
operator to be considered TR for Qt.

Upstream C++ seems to be fine with just providing ① (via P2786), but that 
leaves a huge number of optimizations on the plate: vector insert, erase, swaps 
and swap-based algorithms, etc.; which is a total shame.

I perfectly understand that some types (like the aforementioned "reference 
wrappers", pmr::string, etc.) only allow ① semantics. If upstream cares about 
them so much and doesn't want to lose the opportunity of optimizing vector 
reallocation for them, why haven't they landed _two_ type traits? A generic "is 
trivial relocatable" (that captures construction and assignment) and a more 
specific one (that only captures construction; a subset of the first). It would 
make perfect sense to me to capture different semantics via different traits. 
Not only that, but P2786 has squatted the "trivial relocatable" name for the 
trait, which really belongs to the _more general_ trait.

Oh well, sorry for the rant :-)

> I don't think this accurate, If a library requires additional constraint, 
> they can add them (in addition to checking the type trait), 

But this isn't useful at all; every library has already invented its own 
constraints and type traits. The point of having a language-based solution is 
that the "is TR" property gets automatically propagated when you compose types. 
No library solution can achieve that, especially lacking reflection.

> I don't think we should put efforts into supporting a P1144-based approach.

Do you mean that you would reject a proposal that adds Clang-specific trait 
(with another name) that implements P1144's semantics?

https://github.com/llvm/llvm-project/pull/84621
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits