The vec![..] macro can be used in pattern position with bad diagnostics

[czipperz]

fn main() {
    match Some(vec![3]) {
        Some(vec![x]) => (),
        _ => (),
    }
}

Gives error message:

error: unexpected `(` after qualified path
 --> src/main.rs:3:14
  |
3 |         Some(vec![x]) => (),
  |              ^^^^^^^
  |              |
  |              unexpected `(` after qualified path
  |              in this macro invocation
  |
  = note: this warning originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

But this is clearly wrong as there is no ( in the span pointed to.

[estebank]

This is caused by macro expansion:

$ rustc +nightly file3.rs -Zexternal-macro-backtrace
error: unexpected `(` after qualified path
 --> <::alloc::macros::vec macros>:3:23
  |
1 | / ( $ elem : expr ; $ n : expr ) => (
2 | | $ crate :: vec :: from_elem ( $ elem , $ n ) ) ; ( $ ( $ x : expr ) , * ) => (
3 | | < [ _ ] > :: into_vec ( box [ $ ( $ x ) , * ] ) ) ; ( $ ( $ x : expr , ) * )
  | |                       ^ unexpected `(` after qualified path
4 | | => ( $ crate :: vec ! [ $ ( $ x ) , * ] )
  | |_________________________________________- in this expansion of `vec!`
  |
 ::: file3.rs:3:14
  |
3 |           Some(vec![x]) => (),
  |                -------
  |                |
  |                in this macro invocation
  |                in this macro invocation

error: aborting due to previous error

You cannot pattern match on vectors, but you can pattern match on slices (and even rely on match ergonomics to make it look like you're matching on an array).

[czipperz]

I think it would be nice if this was special cased since it's easily fixable.

[oli-obk]

I reopened this issue (with a title update), because #80080 will reintroduce the issue (with an even odder diagnostic). While trying to come up with a way to fix this issue again with the new system, I came up with the following situation:

Add a way to mark macro_rules declarations with an attribute that declares what their returned AST node type is. Then we mark macro_rules! vec as only producing expressions and add a check during expansion that handles this and reports errors if used wrongly. This will always produce the right error, and we can then also re-add a suggestion if vec! specifically has been used in pattern position.

[oli-obk]

I did some more experimentation, and we could also get away with just changing the vec! macro to enforce it only being used in expression position:

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=43c7b63851e0b5858a60f191543a49ad

macro_rules! vec {
    () => (
        vec!(@force_expr_internal_do_not_use@: $crate::vec::Vec::new())
    );
    ($elem:expr; $n:expr) => (
        vec!(@force_expr_internal_do_not_use@: $crate::vec::from_elem($elem, $n))
    );
    ($($x:expr),+ $(,)?) => (
        vec!(@force_expr_internal_do_not_use@: <[_]>::into_vec(box [$($x),+]))
    );
    (@force_expr_internal_do_not_use@: $e:expr) => ($e);
}

This gives us

error: arbitrary expressions aren't allowed in patterns
  --> src/main.rs:11:48
   |
11 |         vec!(@force_expr_internal_do_not_use@: <[_]>::into_vec(box [$($x),+]))
   |                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
18 |         vec![43] => {},
   |         -------- in this macro invocation
   |
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

though line 15 is probably not going to get shown since the macro is from liballoc

[estebank]

I think that's a reasonable solution. Do you want to cut a PR for it and deleting the now unused code, @oli-obk?

[oli-obk]

I'll write up instructions and hope that someone will pick it up as a good first issue over the holidays. If not, I'll do it before #80080 gets merged.

0. write @rustbot claim in this issue to assign it to yourself
1. cherry pick 5e0401f to remove the old code
2. change the vec! macro in https://github.com/rust-lang/rust/blob/master/library/alloc/src/macros.rs#L41-L51 to the one shown above
3. leave some documentation on the force_expr_internal_do_not_use macro arm explaining that it is to force the ast node type to an expression, thus improving the diagnostics if used in type or pattern position
4. Run ./x.py test src/tests/ui --bless which auto-updates all .stderr files and update all //~ ERROR and other comments that need updating (likely you'll be able to remove some of them entirely because we now only get a single error
5. open a PR (also do that if you get stuck or anything doesn't work) and write r? @oli-obk in the main message so it gets assigned to me

[bugadani]

@rustbot claim