Panic in escape_ascii().len()

[softdevca]

I tried this code:

fn main() {
    "omgwtfbbq".as_bytes().escape_ascii().len();
}

I expected the length of theescape_ascii iterator. Instead, panic:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `None`,
 right: `Some(0)`', /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/iter/traits/exact_size.rs:108:9

Meta

rustc 1.62.1 (e092d0b6b 2022-07-16)
binary: rustc
commit-hash: e092d0b6b43f2de967af0887873151bb1c0b18d3
commit-date: 2022-07-16
host: x86_64-unknown-linux-gnu
release: 1.62.1
LLVM version: 14.0.5

My first suspicion would be the size_hint() on the iterator. It also happens in no_std.

Stacktrace:

stack backtrace:
   0: rust_begin_unwind
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/panicking.rs:142:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/panicking.rs:181:5
   4: core::iter::traits::exact_size::ExactSizeIterator::len
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/iter/traits/exact_size.rs:108:9
   5: omgwtfbbq::main
             at ./src/main.rs:2:5
   6: core::ops::function::FnOnce::call_once
             at /rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/core/src/ops/function.rs:248:5

[thomcc]

This is pretty unfortunate. This type should not implement ExactSizeIterator, but it has for a few stable versions now :(

See also #77174 (the original tracking issue) and #83130 (the PR that added it)

[the8472]

Nominating for discussion whether the stabilization should be reverted, the crater run should be expedited and perhaps beta-backported.

[softdevca]

I would prefer stabilization to be reverted as there is additional book-keeping required to implement ExactSizeIterator.

[m-ou-se]

We discussed this briefly in the libs-api meeting last week. Reverting it seems okay, even though it's technically a breaking change. It seems like nothing relies on it, as they would have gotten panics anyway. The crater run seems to confirm that.