Parse subslice patterns

[tomjakubowski]

This attempt detects subslice patterns in the same place as range patterns;
when the right hand side of a .. in a potential range definitely isn't a pattern,
the parser stops and emits a SUBSLICE_PAT instead.

cc #1479

[tomjakubowski]

@matklad you said the adjustment would need to be in slice_pat but I couldn't figure that out.

In an example like let [a, b, c..], pattern_r() errored in the range pattern branch, on forms like let [a, b, c..] = [], because it would call atom_pat() on the ] token. I didn't see a way to work around this without changing pattern_r(). It was also easier to make more complicated subslice patterns like [ref a..] parse this way.

It's unfortunate that subslice patterns can be parsed outside of slice patterns. I think I can fix that by adding a bool flag to pattern()/pattern_r() signaling whether to parse subslice patterns. That seems a little gross, which often suggests there's a better design...

[matklad]

Hm, I think this is still not exactly what we want, as it'll match [1..], which is wrong: we need to enfroce that lhs is identifier.

I think the best solution would be to inline pat_list into slice_pat and handle a.. specially, simliar to ..:

T![..] => p.bump(),

[matklad]

That is, special casing should happen around here: https://github.com/rust-analyzer/rust-analyzer/blob/5b19825e376b67aabbe8d5b163bf69b1acd92f04/crates/ra_parser/src/grammar/patterns.rs#L241

[matklad]

Ah, yeah, I see pat_list is already inlined! So, we only need to pull haling of .. out of pattern_with_subslice_patterns into the while !p.at(EOF) && !p.at(T![']']) { loop

[tomjakubowski]

OK, this commit copies from atom_pat() to detect binding patterns (including ref mut box a) in slice_pat(). If .. is then eaten, a SUBSLICE_PAT token is emitted, otherwise just the regular binding pattern.

rustc does actually parse .. after some other kinds of patterns, like path patterns and certain literals, but I suspect it's not meant to: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=19d785643aba0341309d7c5b08098ad7

[tomjakubowski]

I think this won't parse macro patterns followed by .., like in let [m!(a).., b] = []. Maybe that case could be handled in the branch that calls pattern(): check if it returned a MACRO_CALL; if so, try and eat a .. and potentially emit a SUBSLICE_PAT.

[matklad]

Wow, looks like I don't really understand what this syntax means in the first place... I would expect that macros wouldn't be allowed to the left of ..... Asked a clarifying question in the original issue.

[matklad]

Ok, so after reading through several RFC, it looks like x.. is an old syntax which will be changed soon, so there's no real reason to support it. Rather, we should move in the direction of rust-lang/rfcs#2707, which just makes .. a pattern of its own.

Chasing unstable features is annoying :)

[Centril]

Ok, so after reading through several RFC, it looks like x.. is an old syntax which will be changed soon, so there's no real reason to support it. Rather, we should move in the direction of rust-lang/rfcs#2707, which just makes .. a pattern of its own.

The syntax x.. is removed and replaced with .. as a pattern in rust-lang/rust#62550.

[Centril]

UPDATE: The PR rust-lang/rust#62550 has been merged.

[matklad]

closing due to inactivity!