ICE vec iter

[smallB007]

Code

fn main() {
    let v = vec![0123456789];
    let mid = v.len() / 2;
    let s = &v;
    match s {
        [a..mid, mid, mid..b] => {}
        [..] => {}
    }
}

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.57.0 (f1edd04 2021-11-29) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type bin

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack

Meta

rustc --version --verbose:

<version>

Error output

<output>

Backtrace

<backtrace>

[matthiaskrgr]

   Compiling v v0.1.0 (/tmp/v)
error[E0425]: cannot find value `a` in this scope
 --> src/main.rs:7:10
  |
7 |         [a..mid, mid, mid..b] => {}
  |          ^ help: a local variable with a similar name exists: `s`

error[E0425]: cannot find value `b` in this scope
 --> src/main.rs:7:28
  |
7 |         [a..mid, mid, mid..b] => {}
  |                            ^ help: a local variable with a similar name exists: `s`

error[E0658]: exclusive range pattern syntax is experimental
 --> src/main.rs:7:10
  |
7 |         [a..mid, mid, mid..b] => {}
  |          ^^^^^^
  |
  = note: see issue #37854 <https://github.com/rust-lang/rust/issues/37854> for more information
  = help: add `#![feature(exclusive_range_pattern)]` to the crate attributes to enable

error[E0658]: exclusive range pattern syntax is experimental
 --> src/main.rs:7:23
  |
7 |         [a..mid, mid, mid..b] => {}
  |                       ^^^^^^
  |
  = note: see issue #37854 <https://github.com/rust-lang/rust/issues/37854> for more information
  = help: add `#![feature(exclusive_range_pattern)]` to the crate attributes to enable

thread 'rustc' panicked at 'expected `NodeId` to be lowered already for res Local(
    NodeId(40),
)', compiler/rustc_ast_lowering/src/lib.rs:563:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.59.0-nightly (91a0600a5 2021-12-18) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type bin

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack
Some errors have detailed explanations: E0425, E0658.
For more information about an error, try `rustc --explain E0425`.
error: could not compile `v` due to 4 previous errors

[matthiaskrgr]

reduced:

fn main() {
    match &vec![0] {
        [a..1, a, a..1] | _ => {}
    }
}

[compiler-errors]

Minimized this a tiny bit further, and I have a detailed explanation why this occurs:

fn main() {
    match () {
        [a.., a] => {}
    }
}

So this bug first starts going wrong in late resolution. Specifically, LateResolutionVisitor::resolve_pattern_inner, we define the a as a binding when we see the second element a (ident subpattern) of the slice pattern, and then bind it later when we walk thru the (expression!) a in the first slice pattern element.

Essentially, since we treat a as being defined here:

[a.., a]
      ^

and then resolve that as the path for

[a.., a]
 ^

we reach a situation where we expect a variable to have been defined before it has been lowered in HIR, which leads to the ICE later on, since we expect to have lowered that path element.

[compiler-errors]

Wonder how difficult it would be to make PatKind::Range have subpatterns instead of subexpressions...

edit: wouldn't help, see below..

[compiler-errors]

Actually, I don't think fixing this just for ranges is sufficient. I can reproduce this same issue with this:

macro_rules! funny {
    ($a:expr, $b:ident) => {
        match [1, 2] {
            [$a, $b] => {}
        }
    }
}

fn main() {
    funny!(a, a);
}

Maybe I can just delay this panic as a span bug, since we're always gonna error out anyways. I think I would ideally like to fix this by making sure we separate bindings in patterns from affecting resolution for expressions in patterns.

edit: Ended up fixing it the right way.

[compiler-errors]

@rustbot claim