Implement `From<Vec<T>>` and `Into<Vec<T>>` for `VecDeque<T>`

[davidhewitt]

No description provided.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[davidhewitt]

Ah, looks like I got the stability attribute wrong. Do I need to change the feature from rust1 to e.g. vecdeque_vec_conversions ?

[apasel422]

If you declare other to be mut, this can just be:

let other_buf = other.as_mut_ptr();

(The transmute is unnecessary.)

[apasel422]

@davidhewitt These impls should probably start off unstable. You can use vecdeque_vec_conversions as the feature name, and #32848 as the issue number. I forgot that we'd need to keep a tracking issue open, so let's actually remove "Closes #32848" from the PR message.

[apasel422]

It'd be good to test for the power-of-two invariant in your test for this method.

[apasel422]

Can you add some additional test cases here with varying vec lengths and capacities? It might be easiest to do something like:

#[test]
fn test_from_vec() {
    for cap in 0..35 {
        for len in 0..cap + 1 {
            let mut vec = Vec::with_capacity(cap);
            vec.extend(0..len);

            let vd = VecDeque::from(vec.clone());
            assert!(vd.cap().is_power_of_two());
            assert_eq!(vd.len(), vec.len());
            assert!(vd.into_iter().eq(vec));
        }
    }
}

[apasel422]

This could also benefit from some other test cases to ensure that the use of wrap_copy is correct, with varying item layouts (contiguous, wrapping, etc).

[alexcrichton]

Thanks for the PR @davidhewitt! @apasel422 unfortunately we don't actually read stability annotations on trait impls right now, so these'll be insta-stable if they land (so #[stable] is fine).

It's also interesting implementing the Into trait instead of the From trait as From<VecDeque<T>> for Vec<T>. Right now we pretty consistently implement From rather than Into (as it also gives you the into method). Would that be possible to do, or is that not allowed because of privacy just yet?

[apasel422]

@alexcrichton Hmm, I didn't even consider the From/Into distinction when I filed the issue, but yes, we should use whatever convention we've been going with.

[davidhewitt]

Hi guys, I'm working on some corrections to this PR, might be a couple of evenings before they land if that's ok?

R.E. the From / Into - shall I rework the Into into a From on the Vec class?

[alexcrichton]

@davidhewitt no worries! Feel free to ping this PR when it's updated. And yeah let's try to put From on Vec directly, but if it's too hard we can discuss that at libs triage.

[davidhewitt]

@apasel422 @alexcrichton So I've taken the first round of comments on board and rewritten this patch with better tests, and covered some corner cases uncovered during testing. Thanks for the feedback, I feel I learned some good stuff with how to make better tests there!

RE. putting the From on Vec, I can do this as long as it's implemented in vec_deque.rs, and not vec.rs. That feels a little weird to me, but privacy stops it working the other way around. Does that feel okay with you guys?

[alexcrichton]

Looks like a stray println?

[alexcrichton]

Thanks for the update @davidhewitt! The libs team discussed this in triage yesterday and the conclusion was that this is good-to-go (especially now that both impls are From rather than one of each).

I'll leave the r+ to @apasel422 though :)

@bors: delegate=apasel422

[bors]

✌️ @apasel422 can now approve this pull request

[davidhewitt]

Thanks @alexcrichton!

@apasel422 - I took "Closes #32848" out of the PR message, just checking that's what you wanted?

[apasel422]

Would it be possible to ensure that test_vec_from_vecdeque explicitly tests each of the four cases?

[apasel422]

This looks good, pending some additional tests. Once you've done that, could you squash all the commits into one?

[davidhewitt]

I rewrote test_vec_from_vecdeque to expand out the loops, to label which configurations of the loop variables will be testing which bits of the ring-straightening algorithm. Also squashed the commits.

Is there other tests you have in mind?

[apasel422]

Looks like there are a few lines longer than 100 characters. Otherwise, this is ready to merge.

[apasel422]

@davidhewitt Looks like this failed with a syntax error.

[davidhewitt]

Sorry, made a mistake breaking up the lines. :/

[apasel422]

@alexcrichton Is 1.9.0 the right value for since?

[alexcrichton]

Ah nah we're on to 1.10.0 at this point. Should write a tidy check for that somehow...

[davidhewitt]

Ah okay - I'll fix that up tonight!

[apasel422]

@bors r+ 1861951

[bors]

⌛️ Testing commit 1861951 with merge 14f61c8...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-cargotest, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-64-x-armhf, auto-linux-64-x-armsf, auto-linux-64-x-freebsd, auto-linux-64-x-netbsd, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-cross-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-mir, auto-win-msvc-64-opt-rustbuild