Rollup of 6 pull requests #147036
Closed
Rollup of 6 pull requests #147036
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
These functions used to be shared with the JSON backend but nowadays they aren't.
…act_if`
The implementation of the `Vec::extract_if` iterator violates the safety
contract adverized by `slice::from_raw_parts` by always constructing a
mutable slice for the entire length of the vector even though that span
of memory can contain holes from items already drained. The safety
contract of `slice::from_raw_parts` requires that all elements must be
properly initialized.
As an example we can look at the following code:
```rust
let mut v = vec![Box::new(0u64), Box::new(1u64)];
for item in v.extract_if(.., |x| **x == 0) {
drop(item);
}
```
In the second iteration a `&mut [Box<u64>]` slice of length 2 will be
constructed. The first slot of the slice contains the bitpattern of an
already deallocated box, which is invalid.
This fixes the issue by only creating references to valid items and
using pointer manipulation for the rest. I have also taken the liberty
to remove the big `unsafe` blocks in place of targetted ones with a
SAFETY comment. The approach closely mirrors the implementation of
`Vec::retain_mut`.
Signed-off-by: Petros Angelatos <[email protected]>
Vec::try_remove is a non-panicking version of Vec::remove
Memory was allocated via `Box::leak` and thence intended to be tracked and deallocated manually, but the allocator was also leaked, not tracked, and never dropped. Now it is dropped immediately. According to my reading of the `Allocator` trait, if a copy of the allocator remains live, then its allocations must remain live. Since the B-tree has a copy of the allocator that will only be dropped after the nodes, it's safe to not store the allocator in each node (which would be a much more intrusive change).
Escape "special characters" (e.g., double quotes `"` and line breaks `\n`). Escape HTML. Lastly, add regression tests and clean up existing tests.
…pr-heuristic, r=rustdoc rustdoc: hide `#[repr]` if it isn't part of the public ABI > [!IMPORTANT] > Temporarily stacked on top of PR rust-lang#146527; only the last commit is relevant! Follow-up to rust-lang#115439. Unblocks rust-lang#116743, CC `@dtolnay.` Fixes rust-lang#66401. Fixes rust-lang#128364. Fixes rust-lang#137440. Only display the representation `#[repr(REPR)]` (where `REPR` is not `Rust` or `transparent`) of a given type if none of its variants (incl. the synthetic variants of structs) are `#[doc(hidden)]` and all of its fields are public and not `#[doc(hidden)]` since it's likely not meant to be considered part of the public ABI otherwise. `--document-{private,hidden}-items` works as expected in this context, too. Moreover, we now also factor in the presence of `#[doc(hidden)]` when checking whether to show `repr(transparent)` or not.
…=fmease [rustdoc] Add support for associated items in "jump to def" feature Fixes rust-lang#135485. r? `@fmease`
avoid violating `slice::from_raw_parts` safety contract in `Vec::extract_if`
The implementation of the `Vec::extract_if` iterator violates the safety contract adverized by `slice::from_raw_parts` by always constructing a mutable slice for the entire length of the vector even though that span of memory can contain holes from items already drained. The safety contract of `slice::from_raw_parts` requires that all elements must be properly
initialized.
As an example we can look at the following code:
```rust
let mut v = vec![Box::new(0u64), Box::new(1u64)];
for item in v.extract_if(.., |x| **x == 0) {
drop(item);
}
```
In the second iteration a `&mut [Box<u64>]` slice of length 2 will be constructed. The first slot of the slice contains the bitpattern of an already deallocated box, which is invalid.
This fixes the issue by only creating references to valid items and using pointer manipulation for the rest. I have also taken the liberty to remove the big `unsafe` blocks in place of targetted ones with a SAFETY comment. The approach closely mirrors the implementation of `Vec::retain_mut`.
**Note to reviewers:** The diff is easier to follow with whitespace hidden.
feat: non-panicking `Vec::try_remove`
`if index < my_vector.len() { Some(my_vector.remove(index)) } else { None }` is annoying to write and non-panicking functions are broadly useful.
APC: rust-lang/libs-team#649
Tracking issue: rust-lang#146954
…joboet BTreeMap: Don't leak allocators when initializing nodes Memory was allocated via `Box::leak` and thence intended to be tracked and deallocated manually, but the allocator was also leaked, not tracked, and never dropped. Now it is dropped immediately. According to my reading of the `Allocator` trait, if a copy of the allocator remains live, then its allocations must remain live. Since the B-tree has a copy of the allocator that will only be dropped after the nodes, it's safe to not store the allocator in each node (which would be a much more intrusive change). Fixes: rust-lang#106203
…tion, r=joboet Add doc for `NonZero*` const creation I ran into trouble using `NonZero*` values because I didn’t see any clear way to create them at compile time. At first I ended up using `NonZero*::new_unchecked` a lot, until I realized that `Option::unwrap` and `Option::expect` are `const` and can be used in a `const` context. With that, you can create non-zero values at compile time safely, without touching `unsafe`. This wasn’t obvious to me and my peers who’ve been using Rust for a while, so I thought adding a note to the docs would make it easier for others to discover. If this should be worded differently or placed in another location, we can do that. I just want to make this more obvious.
rustbot
added
A-attributes
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
#[repr]if it isn't part of the public ABI #116882 (rustdoc: hide#[repr]if it isn't part of the public ABI)slice::from_raw_partssafety contract inVec::extract_if#141032 (avoid violatingslice::from_raw_partssafety contract inVec::extract_if)Vec::try_remove#146293 (feat: non-panickingVec::try_remove)NonZero*const creation #146924 (Add doc forNonZero*const creation)Failed merges:
alloc-variant-zeroedto LLVM #144086 - clubby789:alloc-zeroed, r=nikic")r? @ghost
@rustbot modify labels: rollup
Create a similar rollup