[PATCH] D115443: [ADT] Weaken the initialization condition in SmallVector::resize_for_overwrite
James Player via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jan 13 18:02:13 PST 2022
jplayer-nv added a comment.
> Older MSVC has trouble with is_trivially_copyable
If I recall correctly from https://reviews.llvm.org/D93510, the original problem was not due to `std::is_trivially_copyable` being wrong. It was just an insufficient condition to select the trivial `OptionalStorage` specialization because there were additional assumptions rolled up into taking that specialization. The `Optional` bug existed independent of the changes MSVC made to the `std::pair` class (which triggered the compile failure in my build environment).
In theory, we could separate these assumptions into to multiple specializations of the trivial `OptionalStorage` specialization omitting copy/move constructors and cover the entire breadth of `std::is_trivially_copyable` types.
---
**For this review:**
My concern would be the variations in the result of `std::is_trivially_copyable` across different c++ standards. It's possible that you could have a class considered non-trivially copyable in one compiler and trivially copyable in another. This means that it becomes unclear whether you can populate the buffer with `std::uninitialized_copy` or you should call `std::copy` (for example).
Personally, I don't think `resize_for_overwrite()` should construct values regardless of type traits. In that case, `std::uninitialized_copy()` and `std::uninitialized_fill()` would always be appropriate follow-ups.
Are there currently many instances of `resize_for_overwrite()` called for a non-POD type?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D115443/new/
https://reviews.llvm.org/D115443
More information about the llvm-commits
mailing list