https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=perf-tmp 2025-09-25T18:52:03+00:00 2025-09-25T18:52:03+00:00 Noratrieb 48135649+Noratrieb@users.noreply.github.com 2025-09-25T18:36:58+00:00 urn:sha1:9316d4508c42d5e6d91480aec34f66462801ee5d They cause significant binary size overhead while contributing little value. Also removes them from the wrapping String methods that do not panic. 2025-09-25T10:31:51+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-09-25T10:31:51+00:00 urn:sha1:2acd80cfa928c1371d2c60149b3febe66c9e6637 RawVecInner: add missing `unsafe` to unsafe fns Some (module-private) functions in `library/alloc/src/raw_vec/mod.rs` are unsafe (i.e. may cause UB when called from safe code) but are not marked `unsafe`. Specifically: - `RawVecInner::grow_exact` causes UB if called with `len` and `additional` arguments such that `len + additional` is less than the current capacity. Indeed, in that case it calls [Allocator::grow](https://doc.rust-lang.org/std/alloc/trait.Allocator.html#method.grow) with a `new_layout` that is smaller than `old_layout`, which violates a safety precondition. - The RawVecInner methods for resizing the buffer cause UB if called with an `elem_layout` different from the one used to initially allocate the buffer, because in that case `Allocator::grow` or `Allocator::shrink` are called with an `old_layout` that does not *fit* the allocated block, which violates a safety precondition. - `RawVecInner::current_memory` might cause UB if called with an `elem_layout` different from the one used to initially allocate the buffer, because the `unchecked_mul` might overflow. - Furthermore, these methods cause UB if called with an `elem_layout` where the size is not a multiple of the alignment. This is because `Layout::repeat` is used (in `layout_array`) to compute the allocation's layout when allocating, which includes padding to ensure alignment of array elements, but simple multiplication is used (in `current_memory`) to compute the old allocation's layout when resizing or deallocating, which would cause the layout used to resize or deallocate to not *fit* the allocated block, which violates a safety precondition. I discovered these issues while performing formal verification of `library/alloc/src/raw_vec/mod.rs` per [Challenge 19](https://model-checking.github.io/verify-rust-std/challenges/0019-rawvec.html) of the [AWS Rust Standard Library Verification Contest](https://aws.amazon.com/blogs/opensource/verify-the-safety-of-the-rust-standard-library/). 2025-09-21T17:12:20+00:00 Ben Kimock kimockb@gmail.com 2025-09-18T14:48:18+00:00 urn:sha1:df58fd8cf7710f7516c541769a141f0235978dab 2025-09-21T17:12:18+00:00 Ben Kimock kimockb@gmail.com 2025-09-07T16:31:35+00:00 urn:sha1:888679013d1f424adef06267f3630069b4cabd40 2025-09-05T08:21:21+00:00 Bart Jacobs bart.jacobs@cs.kuleuven.be 2025-08-07T19:27:12+00:00 urn:sha1:96f385b20aa252629570cadeca16a9e159e6810c - RawVecInner::grow_exact causes UB if called with len and additional arguments such that len + additional is less than the current capacity. Indeed, in that case it calls Allocator::grow with a new_layout that is smaller than old_layout, which violates a safety precondition. - All RawVecInner methods for resizing the buffer cause UB if called with an elem_layout different from the one used to initially allocate the buffer, because in that case Allocator::grow/shrink is called with an old_layout that does not fit the allocated block, which violates a safety precondition. - RawVecInner::current_memory might cause UB if called with an elem_layout different from the one used to initially allocate the buffer, because the unchecked_mul might overflow. - Furthermore, these methods cause UB if called with an elem_layout where the size is not a multiple of the alignment. This is because Layout::repeat is used (in layout_array) to compute the allocation's layout when allocating, which includes padding to ensure alignment of array elements, but simple multiplication is used (in current_memory) to compute the old allocation's layout when resizing or deallocating, which would cause the layout used to resize or deallocate to not fit the allocated block, which violates a safety precondition. 2025-09-04T00:01:53+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-09-04T00:01:53+00:00 urn:sha1:d71a9b6bcf9aae816291c560432b728f7d7f3494 raw_vec.rs: Remove superfluous fn alloc_guard `alloc_guard` checks that its argument is at most `isize::MAX`, but it is called only with layout sizes, which are already guaranteed to be at most `isize::MAX`. 2025-09-03T05:34:32+00:00 Bart Jacobs bart.jacobs@cs.kuleuven.be 2025-08-22T13:28:37+00:00 urn:sha1:d9dc20c7529d93ba4e1f91c9e44fb882c07aa1c0 It checks that its argument is at most isize::MAX, but it is called only with layout sizes, which are already guaranteed to be at most isize::MAX. 2025-08-26T20:58:44+00:00 Tobias Stoeckmann tobias@stoeckmann.org 2025-08-26T20:44:09+00:00 urn:sha1:45296bb633bc7fdd0c692a8be3035393ec3c9314 Turn "any heap allocators" into "any heap allocator". 2025-07-22T12:28:48+00:00 Guillaume Gomez guillaume1.gomez@gmail.com 2025-07-21T12:34:12+00:00 urn:sha1:a27f3e3fd1e4d16160f8885b6b06665b5319f56c 2025-05-05T19:56:33+00:00 Vilim Lendvaj vilim.lendvaj@sk.t-com.hr 2025-05-05T19:38:25+00:00 urn:sha1:53459ffa8c0b9060f111b4730d1fe58a110470d9