Terse parse error on `ident @ pat` in destructuring assignment

Consider the following slice pattern:

let arr = [1, 2, 3, 4];
let [a, b, rest @ ..] = arr;
dbg!(a, b, rest); // [src/main.rs:4:5] a = 1
                  // [src/main.rs:4:5] b = 2
                  // [src/main.rs:4:5] rest = [
                  //     3,
                  //     4,
                  // ]

Now, consider the following destructuring assignment with a slice pattern, including a "rest" pattern:

let (c, d);
[c, .., d] = [1, 2, 3, 4];
dbg!(c, d); // [src/main.rs:13:1] c = 1
            // [src/main.rs:13:1] d = 4

Now, consider the following destructuring assignment with a slice pattern, again in this Playground:

let e;
let rest;
let f;
[e, rest @ .., f] = [1, 2, 3, 4];
dbg!(e, rest, f);
/*
error: expected one of `!`, `,`, `.`, `::`, `?`, `]`, `{`, or an operator, found `@`
  --> src/main.rs:19:10
   |
19 | [e, rest @ .., f] = [1, 2, 3, 4];
   |          ^ expected one of 8 possible tokens

error: expected one of `!`, `#`, `(`, `,`, `.`, `::`, `;`, `?`, `[`, `]`, `_`, `async`, `become`, `break`, `continue`, `for`, `if`, `let`, `loop`, `match`, `move`, `return`, `static`, `unsafe`, `while`, `yield`, `{`, `|`, `||`, `}`, an operator, or path, found `@`
  --> src/main.rs:19:10
   |
19 | [e, rest @ .., f] = [1, 2, 3, 4];
   |          ^ expected one of 32 possible tokens
*/

...that wasn't really what I expected! But then, I don't know what I did expect, honestly. It's possible this is "just" a diagnostic issue, but this is one of the somewhat sharper inconsistencies to discover here. I suspect gating this during parsing is not the correct thing to do here, even if we want to error on it.

@rustbot label: +C-bug +T-compiler +T-lang +D-confusing +A-parser +A-slice-patterns

Reproduce the slice-pattern destructuring assignment in the linked Rust Playground and compare it with the working rest-pattern examples in the issue. Start by tracing the parser handling for rest @ ..; done should clarify whether the syntax is supported and, if not, provide a consistent diagnostic rather than the terse token errors shown.