Add unstable VecDeque::rotate_{left|right}

[scottmcm]

Like the ones on slices, but more efficient because vecdeque is a circular buffer.

Issue that proposed this: #56686

💣 Please someone look very carefully at the unsafe in this! The wrap_copy seems to be exactly what this method needs, and the len passed to it is never more than half the length of the deque, but I haven't managed to prove to myself that it's correct 💣 I think I proved that this code meets the requirement of the unsafe code it's calling; please double-check, of course.

[rust-highfive]

r? @dtolnay

(rust_highfive has picked a reviewer for you, use r? to override)

[dtolnay]

This does not hit the #30459 RTL naming issue right?

The implementation looks good to me. r? @alexcrichton for another look at the unsafe code.

r? @alexcrichton

[scottmcm]

I believe this doesn't hit the #30459 RTL issue because it's not on text, and thus is like the rotate_left/rotate_right on integers and slices.

I've pushed a new commit with a claim for why this is safe; please double-check it.

[ollie27]

VedDeque is front to back in Rust so for consistency with the rest of the API these methods should be named something like rotate_forward or rotate_to_front. VedDeque has no concept of a left or a right. This is in contrast to Python deque which does use left to right.

[alexcrichton]

I'm not super familiar with the implementation of VecDeque, but this seems fine to me to at least land unstable. I'd ideally prefer to see more tests though especially as this has some unsafety, it looks like there's already internal branches but it may not be covered by tests so far? (things like zero len, over half, under half, etc).

It's true that rotate_left does match integers, but it seems prudent to try think of names at least which match the front/back naming @ollie27 mentioned that's already with VecDeque. Something like rotate_to_front and rotate_to_back would make sense to me too

[scottmcm]

I'll add some more tests.

Since [T]::rotate_left has been stable since 1.26, I think consistency with that is more important than "frontward" names. See previous discussion of the rotate->rotate_left rename in #41891 (comment)

[CryZe]

rotate_to_front and rotate_to_back would be ambiguous anyway. The problem here is your viewpoint. Rotating to the back moves all the elements inside the VecDeque from the front to the back, but the ones that fall out of the back get moved to the front. So they traveled from the back to the front, even though the method name suggested we move from the front to the back. That's because rotating from point A to point B on a circle can be done either clockwise or counter clockwise. So from_a_to_b is ambiguous. So the naming would either have to be clockwise / counter_clockwise or left / right to not be ambiguous.

[alexcrichton]

Ah if rotate_{left,right} are already on slices then makes sense to me to leave the names as-is on VecDeque!

[alexcrichton]

@bors: r+

[bors]

📌 Commit cbe9abb has been approved by alexcrichton

[bors]

⌛ Testing commit cbe9abb with merge 04cfa08155cf0c5d7bdec75b7f0f7fd8d8bb4526...

[bors]

💔 Test failed - status-travis

[rust-highfive]

The job x86_64-gnu-distcheck of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:03:25]    Compiling cargo v0.32.0
[00:03:32] error[E0308]: mismatched types
[00:03:32]  --> /cargo/registry/src/git.luolix.top-1ecc6299db9ec823/cargo-0.32.0/src/cargo/util/sha256.rs:9:34
[00:03:32]   |
[00:03:32] 9 |         let hasher = Hasher::new(Algorithm::SHA256);
[00:03:32]   |                                  |
[00:03:32]   |                                  |
[00:03:32]   |                                  expected reference, found enum `util::sha256::crypto_hash::Algorithm`
[00:03:32]   |                                  help: consider borrowing here: `&Algorithm::SHA256`
[00:03:32]   |
[00:03:32]   = note: expected type `&util::sha256::crypto_hash::Algorithm`
[00:03:32]              found type `util::sha256::crypto_hash::Algorithm`
[00:03:32] error: aborting due to previous error
[00:03:32] 
[00:03:32] For more information about this error, try `rustc --explain E0308`.
[00:03:32] For more information about this error, try `rustc --explain E0308`.
[00:03:32] error: failed to compile `cargo-vendor v0.1.22`, intermediate artifacts can be found at `/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-bootstrap-tools`
[00:03:32] Caused by:
[00:03:32]   Could not compile `cargo`.
[00:03:32] 
[00:03:32] To learn more, run the command again with --verbose.
[00:03:32] To learn more, run the command again with --verbose.
[00:03:32] 
[00:03:32] 
[00:03:32] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "install" "-j" "4" "--locked" "--color" "always" "--force" "--debug" "--vers" "0.1.22" "cargo-vendor"
[00:03:32] 
[00:03:32] 
[00:03:32] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test distcheck
[00:03:32] Build completed unsuccessfully in 0:01:37
---
travis_time:end:011d77f4:start=1545333368872761108,finish=1545333368880427904,duration=7666796
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0357c490
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:0d6db535
travis_time:start:0d6db535
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:092ec13a
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[alexcrichton]

@bors: retry

• 0.3.2 contains a breaking change malept/crypto-hash#6

[bors]

⌛ Testing commit cbe9abb with merge 9689ada...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 9689ada to master...