rjmccall added a comment. In https://reviews.llvm.org/D50119#1303423, @Quuxplusone wrote:
> In the `unordered_set [[maybe_trivially_relocatable]]` patch, I must wrap the > attribute in a macro `_LIBCPP_MAYBE_TRIVIALLY_RELOCATABLE_UNLESS_DEBUG`. > Without this caveat, I would have ended up with //unsafe behavior// in debug > mode. The `unordered_set [[trivially_relocatable]]` patch does not have this > danger; the fact that we break the Rule of Zero in debug mode is sufficient > to disable trivial relocatability. Can you elaborate? Providing a non-defaulted copy/move constructor or destructor should make an unannotated class non-trivially-relocatable under both rules. > In the `unordered_set [[maybe_trivially_relocatable]]` patch, I must either > pipe the attribute down through `unique_ptr`, or else give up using > `unique_ptr` in `__hash_table`. I chose to modify `unique_ptr`; but note that > many working programmers wouldn't have this luxury. In the `unordered_set > [[trivially_relocatable]]` patch, I don't need to modify `unique_ptr`; I just > use the "triviality-forcing wrapper" pattern. Sure, this is an acknowledged downside of `[[maybe_trivially_relocatable]]` for third-party programmers. > I still believe it is impossible to implement `std::optional` with only > `[[maybe_trivially_relocatable]]`. This might also need elaboration. Repository: rC Clang https://reviews.llvm.org/D50119 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
