[PATCH] D115443: [ADT] Weaken the initialization condition in SmallVector::resize_for_overwrite

Benjamin Kramer via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 17 09:47:32 PST 2022


bkramer added a comment.

In D115443#3242421 <https://reviews.llvm.org/D115443#3242421>, @jplayer-nv wrote:

> 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).

But is this really a problem? If `std::is_trivially_copyable` isn't aggressive you get redundant initializations, but it's not a bug. ABI-wise this should also be fine because no struct layout is affected.

> 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.

I somewhat agree, but I'm really concerned about cases like

  {
    SmallVector<std::unique_ptr<T>> v;
    v.resize_for_overwrite(42);
  }
  <crash in destructor>

And also operator= no longer working. Maybe it's not an issue in reality ...

> Are there currently many instances of `resize_for_overwrite()` called for a non-POD type?

No, this function is only used on PODs. I was planning to use it on SmallVectors of SourceLocations in Clang.


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