-
-
Notifications
You must be signed in to change notification settings - Fork 14.3k
add VecDeque::splice #147247
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
add VecDeque::splice #147247
Conversation
|
Thanks for working on this! |
|
Sorry I haven't had a chance to look at this, still behind on my reviews r? libs |
|
☔ The latest upstream changes (presumably #148337) made this pull request unmergeable. Please resolve the merge conflicts. |
| // This will set drain.remaining to 0, so its drop won't try to read deallocated memory on | ||
| // drop. | ||
| self.drain.by_ref().for_each(drop); | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need something like
rust/library/alloc/src/vec/splice.rs
Line 62 in 87f9dcd
| self.drain.iter = (&[]).iter(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understand it, the for_each will ensure that remaining is set to 0, so Drain::drop won't drop anything. I intentionally use Drain::drop to put the elements together again properly.
| unsafe fn move_tail(&mut self, additional: usize) { | ||
| let deque = unsafe { self.deque.as_mut() }; | ||
| let tail_start = deque.len + self.drain_len; | ||
| deque.buf.reserve(tail_start + self.tail_len, additional); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have coverage for this reserve running? Normally growing VecDeque requires extra logic AFAICT, not just reserving the underlying buffer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should run anytime the new iterator (replace_with) has a different length than the removed elements, which is definitely tested. Do you have a more specific case in which this could cause issues?
a9f20e3 to
003ebda
Compare
This comment has been minimized.
This comment has been minimized.
003ebda to
f01287c
Compare
This comment has been minimized.
This comment has been minimized.
|
I'm not sure why the CI isn't running, but all the requested changes should be good |
|
r=me with a rebase |
f01287c to
0763954
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
@Mark-Simulacrum should be good, but I don't have permission to r=you. |
|
@bors r+ |
|
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing f0864c8 (parent) -> 0e89999 (this PR) Test differencesShow 322 test diffsStage 1
Stage 2
Additionally, 306 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 0e8999942552691afc20495af6227eca8ab0af05 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (0e89999): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary 4.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 481.996s -> 480.336s (-0.34%) |
Tracking issue: #146975