Skip to content
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

Remove &[T] from vec_deque::Drain #101299

Merged
merged 2 commits into from
Sep 11, 2022
Merged

Conversation

saethlin
Copy link
Member

@saethlin saethlin commented Sep 2, 2022

Fixes #60076

I don't know what the right approach is here. There were a few suggestions in the issue, and they all seem a bit thorny to implement. So I just picked one that was kind of familiar.

@rustbot rustbot added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Sep 2, 2022
@rust-highfive
Copy link
Collaborator

r? @joshtriplett

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 2, 2022
@rust-log-analyzer

This comment has been minimized.

library/alloc/src/collections/vec_deque/iter.rs Outdated Show resolved Hide resolved
}

impl<'a, T> Iter<'a, T> {
pub(super) fn new(ring: &'a [MaybeUninit<T>], tail: usize, head: usize) -> Self {
Iter { ring, tail, head }
Iter {
ring: ptr::slice_from_raw_parts(ring.as_ptr().cast(), ring.len()),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could also be written as ring as *const [MaybeUninit<T>] as *const [T]. Not sure if the as cast is better than a ptr::slice_from_raw_parts call, but in both cases I feel like there should be a better way to write this.

@rust-log-analyzer

This comment has been minimized.

@RalfJung
Copy link
Member

RalfJung commented Sep 9, 2022

r? libs

@rust-highfive rust-highfive assigned thomcc and unassigned joshtriplett Sep 9, 2022
}
}

unsafe fn ring(&self) -> &'a [MaybeUninit<T>] {
Copy link
Member

@RalfJung RalfJung Sep 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a very long-lived reference, is that needed?

In particular, the entire reason this PR is made is that this lifetime is a lie -- when Iter is used in Drain and Drain is dropped, the memory will be deallocated while 'a is still ongoing. That should probably be documented somewhere.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can tell, we need to get a &'a T by some means in order to implement all the iterator methods, so we're stuck with this hazard.

Let's see if I can do something to just Drain to fix the problem there...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The second commit in this PR now reverts the first one and modifies just the Drain struct. Do you think that approach is more satisfying?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't checked the details but I do think that reusing Iter was kind of a hack so this seems cleaner to me indeed.

Let's see what the libs reviewer says.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fine to me.

@rustbot
Copy link
Collaborator

rustbot commented Sep 10, 2022

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

@thomcc
Copy link
Member

thomcc commented Sep 11, 2022

Thanks.

@bors r+

@bors
Copy link
Contributor

bors commented Sep 11, 2022

📌 Commit 54684c4 has been approved by thomcc

It is now in the queue for this repository.

@bors bors 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 Sep 11, 2022
@bors
Copy link
Contributor

bors commented Sep 11, 2022

⌛ Testing commit 54684c4 with merge 59e7a30...

@bors
Copy link
Contributor

bors commented Sep 11, 2022

☀️ Test successful - checks-actions
Approved by: thomcc
Pushing 59e7a30 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 11, 2022
@bors bors merged commit 59e7a30 into rust-lang:master Sep 11, 2022
@rustbot rustbot added this to the 1.65.0 milestone Sep 11, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (59e7a30): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean1 range count2
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.6% [0.6%, 0.6%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-1.2% [-1.2%, -1.2%] 1
All ❌✅ (primary) - - 0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean1 range count2
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.0% [-2.0%, -2.0%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -2.0% [-2.0%, -2.0%] 1

Footnotes

  1. the arithmetic mean of the percent change 2

  2. number of relevant changes 2

@saethlin saethlin deleted the vecdeque-drain-drop branch September 21, 2022 03:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

VecDeque's Drain::drop writes to memory that a shared reference points to