-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 4 pull requests #95393
Rollup of 4 pull requests #95393
Conversation
This is my first PR; be gentle! In https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/2?u=janpaul123 it was suggested to me that I should make a PR to make the documentation of `Vec::from_raw_parts` less strict, since we don't require `T` to have the same size, just `size_of::<T>() * capacity` to be the same, since that is what results in `Layout::size` being the same in `dealloc`, which is really what matters. Also in https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/8?u=janpaul123 it was suggested that it's better to use `slice::from_raw_parts`, which I think is useful advise that could also be mentioned in the docs, so I added that too. Let me know what you think! :)
Clarify that ManuallyDrop<T> has same layout as T This PR implements the documentation change under discussion in rust-lang/unsafe-code-guidelines#302. It should not be approved or merged until the discussion there is resolved.
…s-with-different-allocators, r=dtolnay Allow comparing `Vec`s with different allocators using `==` See https://stackoverflow.com/q/71021633/7884305. I did not changed the `PartialOrd` impl too because it was not generic already (didn't support `Vec<T> <=> Vec<U> where T: PartialOrd<U>`). Does it needs tests? I don't think this will hurt type inference much because the default allocator is usually not inferred (`new()` specifies it directly, and even with other allocators, you pass the allocator to `new_in()` so the compiler usually knows the type). I think this requires FCP since the impls are already stable.
Docs: make Vec::from_raw_parts documentation less strict This is my first PR; be gentle! In https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/2?u=janpaul123 it was suggested to me that I should make a PR to make the documentation of `Vec::from_raw_parts` less strict, since we don't require `T` to have the same size, just `size_of::<T>() * capacity` to be the same, since that is what results in `Layout::size` being the same in `dealloc`, which is really what matters. Also in https://users.rust-lang.org/t/why-does-vec-from-raw-parts-require-same-size-and-not-same-size-capacity/73036/8?u=janpaul123 it was suggested that it's better to use `slice::from_raw_parts`, which I think is useful advise that could also be mentioned in the docs, so I added that too. Let me know what you think! :)
…olnay impl From<&[T; N]> and From<&mut [T; N]> for Vec<T> I really wanted to write: ```rust fn example(a: impl Into<Vec<u8>>) {} fn main() { example(b"raw"); } ```
@bors r+ rollup=never p=5 |
📌 Commit 8bfc03f has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (93313d1): comparison url. Summary: This benchmark run did not return any relevant results. 6 results were found to be statistically significant but too small to be relevant. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Successful merges:
Vec
s with different allocators using==
#93755 (Allow comparingVec
s with different allocators using==
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup