Add invariant to VecDeque::pop_* that len < cap if pop successful by Philippe...
source link: https://github.com/rust-lang/rust/pull/123089
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Conversation
Contributor
Similar to #114370 for VecDeque instead of Vec.
I initially come from rust-itertools/itertools#899 where we noticed that pop_front;push_back; was slower than expected so @scottmcm suggested I file an issue which lead to https://internals.rust-lang.org/t/vecdeque-pop-front-push-back/20483 where kornel mentionned #114334 (fixed by #114370).
This is my first time with codegen tests, I based the test on what was done for Vec.
Collaborator
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Nilstrieb (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue.
labels
This comment has been minimized.
This comment has been minimized.
Contributor
Author
|
I just saw that the |
Member
|
Yeah, that's nicer. |
This comment has been minimized.
Contributor
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
Collaborator
|
Finished benchmarking commit (debc5ab): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results CyclesResults Binary sizeResults Bootstrap: 672.189s -> 671.042s (-0.17%) |
Member
|
No regression, not that I expected any change. |
added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
labels
added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
#[no_mangle] |
||
// CHECK-LABEL: @push_back_byte( |
||
pub fn push_back_byte(v: &mut VecDeque<u8>) { |
thanks for including those tests btw, having the test to make sure the above tests are correct is super important!
Contributor
Author
I merely mimicked the Vec version of this PR.
The 1st iteration was too much Vec-oriented.
Member
|
@bors r+ |
added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
labels
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Successfully merging this pull request may close these issues.
None yet
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK