-
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
replace vec::Drain drop loops with drop_in_place #85157
Conversation
r? @yaahc (rust-highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 5cd25a3c8de8ac50571849c91869d27b0aedf1b4 with merge f43378a4f09d5d51bfbc4bca4d5abbd28238f176... |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
5cd25a3
to
032fa35
Compare
@bors try |
⌛ Trying commit 032fa35 with merge 29e55f8f91bd74ab69933dd9166d41317e0146b7... |
☀️ Try build successful - checks-actions |
Queued 29e55f8f91bd74ab69933dd9166d41317e0146b7 with parent 6fd7a6d, future comparison URL. |
Finished benchmarking try commit (29e55f8f91bd74ab69933dd9166d41317e0146b7): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
seems kind of mixed. @SkiFire13 do you think it would make sense to test your changes on top of these? |
I might give it a try, give me a sec to rebase my pr on top of yours. |
triage: |
Still on my radar, just haven't had a chance to review it yet. |
032fa35
to
6851b8d
Compare
@the8472 if you want to leave the cleanup of spare capacity to something simpler for the future, that seems OK to me as well I think. |
@bors r+ |
📌 Commit 2d8a11b has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (0b42dea): comparison url. Summary: This change led to large relevant improvements 🎉 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Nice, better results than the previous perf run. |
Is it possible that this introduced a use-after-free? |
mem::forget(guard); | ||
let iter = mem::replace(&mut self.iter, (&mut []).iter()); | ||
let drop_len = iter.len(); | ||
let drop_ptr = iter.as_slice().as_ptr(); |
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.
Specifically, Miri says that in this line as_slice
points to dangling memory (in some cases, here triggered by the test_replace_range
testcase)
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.
I'm under the impression that the iter should be valid at all times, but I'll have a closer look at the test-case.
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.
(Continuing in #91772)
The
Drain::drop
implementation came up in #82185 (comment) as potentially interfering with other optimization work due its widespread use somewhere inprintln!
@rustbot label T-libs-impl