Vitaly Buka

Do we need to cc @erwincoumans somehow?

> ping Assuming you are expecting @efriedma-quic reply, don't forget "note" from https://llvm.org/docs/CodeReview.html#acknowledge-all-reviewer-feedback

Is this on staging? just started bots on staging https://lab.llvm.org/staging/#/builders/7 and see 

> Is this on staging? My apologies, I forgot to merge #257.

> Thanks, David! The patch works on the staging well. It does not look like it works. https://lab.llvm.org/staging/#/builders/7 Is this rely on staging?

Any estimates when it will reach lab.llvm.org/buildbot? Asking if we need to return workaround #295.

This is causing new/delete mismatch https://lab.llvm.org/buildbot/#/builders/168/builds/20063 ``` ================================================================= ==2164144==ERROR: AddressSanitizer: new-delete-type-mismatch on 0x5030000035b0 in thread T0: object passed to delete has wrong type: size of the allocated type: 25 bytes;...

@ldionne looks like a bug in std::string ``` --- a/libcxx/include/string +++ b/libcxx/include/string @@ -1123,7 +1123,7 @@ public: inline _LIBCPP_CONSTEXPR_SINCE_CXX20 ~basic_string() { __annotate_delete(); if (__is_long()) - __alloc_traits::deallocate(__alloc(), __get_long_pointer(), __get_long_cap()); + __alloc_traits::deallocate(__alloc(),...

Delete uses __get_long_cap() ``` _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 void __set_long_cap(size_type __s) _NOEXCEPT { __r_.first().__l.__cap_ = __s / __endian_factor; __r_.first().__l.__is_long_ = true; } _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 size_type __get_long_cap() const _NOEXCEPT { return __r_.first().__l.__cap_ *...

I believe previously, maybe a few month ago, it was never more than 1-2 requests.