VecDeque from Vec fails with ZST

[alecmocatta]

This code panics under Miri, and also when I compile to WASM, though not when running normally.

use std::collections::VecDeque;

fn main() {
    let _: VecDeque<()> = vec![()].into();
}

Playground

thread 'main' panicked at 'attempt to add with overflow', /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/collections/vec_deque.rs:3236:36

The overflow is here:

rust/library/alloc/src/collections/vec_deque.rs

Line 3236 in a53fb30

let cap = cmp::max(buf.capacity() + 1, MINIMUM_CAPACITY + 1).next_power_of_two();

[camelid]

I can reproduce when using Miri, but it works fine for me with WASM:

$ cargo +stable build --target=wasm32-unknown-unknown
   Compiling rust-issue-78532 v0.1.0 (/Users/user/rust-issue-78532)
    Finished dev [unoptimized + debuginfo] target(s) in 0.17s

(Same with nightly toolchain.)

[lcnr]

use std::collections::VecDeque;

fn main() {
    let v = vec![(); 100];
    let queue = VecDeque::from(v);
    println!("{:?}", queue);
}

panics with

thread 'main' panicked at 'capacity overflow', library/alloc/src/raw_vec.rs:542:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

it always fails here because len is greater than MINIMUM_CAPACITY so cap - len underflows.

[camelid]

Why is this specific to ZSTs?

[lcnr]

Vec does not allocate for ZST and starts out with capacity usize::MAX which overflows when converting to a deque which does not expect this

[camelid]

Assigning P-high and removing I-prioritize as discussed in the prioritization working group.

[RalfJung]

This code panics under Miri, and also when I compile to WASM, though not when running normally.

Currently on playground it seems to work fine both under Miri and regular rustc? Indeed something would be very wrong if it only panicked on Miri...

@lcnr's version panics both with rustc and Miri. Maybe the example in the OP should be updated.

[alecmocatta]

Currently on playground it seems to work fine both under Miri and regular rustc? Indeed something would be very wrong if it only panicked on Miri...

Yes, though at time of posting it did fail under miri (and only under miri) on the playground.

I can reproduce when using Miri, but it works fine for me with WASM

Sorry if I was unclear; I meant that I got the same panic when running the built WASM.

[RalfJung]

Yes, though at time of posting it did fail under miri (and only under miri) on the playground.

My guess is that something in libstd changed to fix the panic for your case (but not for @lcnr's), and when you tested this, Miri was broken in the latest toolchain so playground had an older version of Miri. When this happens again, please note down the exact versions of every component involved, so we can make sure this is comparing Miri and rustc for the same toolchain, not two different versions of Rust.

[tmiasko]

The originally reported panic is an overflow check and one of those that is not inherited cross-crate. To observe it the standard library must be built with overflow checks. It's still an issue right now.

[RalfJung]

Ah, so this stopped to fail in Miri when we recently stopped building libstd with debug assertions.