Tracking issue for RFC 554: pattern_parentheses feature

[kennytm]

This tracks the pattern_parentheses feature which allows using parenthesis to group patterns.
(relevant RFC issue: rust-lang/rfcs#554).

match x {
    (y) => {}
}

• Implementation (Support parentheses in patterns under feature gate #48500)
• Stabilization
  • Decided to stabilize
  • Need stabilization PR (mentoring instructions)
  • Needs docs

[nikomatsakis]

Nominating for lang-team discussion. I think that we ought to stabilize this feature. It extends the pattern grammar with parentheses — really not much to say about it. That said, looking about the repo i didn't find many tests. One of my motivations is to address the "precedence fix" of ..= patterns described here -- in particular, I'd like you to be able to write &(3 ..= 5). (But I don't know that we have a test for this, will have to check.)

[nikomatsakis]

(Also I think we should make sure to extend the Rust Reference before stabilizing.)

[nikomatsakis]

@rfcbot fcp merge

I would like to move to stabilize this feature. I am going to break my own rules by not providing a stability report that links to tests, but as part of the stabilization PR (or earlier...) we can add some of the tests that I think are missing (or maybe they are there and I did not see them).

What is being stabilized

Introducing the ability to have parenthesized patterns (P). This can be used to enable precedence between patterns, and is specifically needed to have a pattern like &(3 ..= 5) or &(3 ... 5) (note that, for reasons of backwards compatibility, &3 ... 5 is accepted but discouraged).

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams:

• @aturon
• @cramertj
• @eddyb
• @joshtriplett
• @nikomatsakis
• @nrc
• @pnkfelix
• @scottmcm
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[scottmcm]

Definitely feels like this needs careful tests, especially about weird macro stuff I don't understand, but if people are fine with doing that as part of stabilization then I'm fine with that too.

@rfcbot reviewed

[cramertj]

macro_rules! foo {
    ($x:pat) => { "pattern" };
    ($x:expr) => { "expr" };
}

fn main() {
    println!("{}", foo!((4)));
}

This currently compiles on stable in 1.26 and prints "pattern", so we've already stabilized that this syntax parses as a pattern. I think that for changes like this we should start tracking branches hit during parsing in order to feature gate, rather than traversing the resulting AST, which fails to catch cases like this where (4) isn't used as a pattern but parses successfully as a pattern.

[eddyb]

@cramertj We can probably solve that by moving to a sort of "persistent forest" for caching parsed AST fragments, for both macro invocations, but also the $x:foo fragments.
There are other benefits to an approach like that, but this is probably not the place to list them.

(Note that we can't know the feature gate set before parsing and macro-expanding the crate)

[cramertj]

@eddyb

Note that we can't know the feature gate set before parsing and macro-expanding the crate

Right-- I was proposing that we track the set of features used during parsing and macro expansion and only report errors once we had finished and seen that the list of features used wasn't a subset of the features enabled.

[scottmcm]

This probably doesn't rise to a full concern, but I think the unused_parens lints must be extended to also catch unused parentheses in patterns before this gets stabilized.

    match (1) { // Warns, as expected
        (_) => {} // Doesn't warn, but should for consistency
    }

https://play.rust-lang.org/?gist=9f08276033eab518cd8055ff148c266a&version=nightly

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[nrc]

@rust-lang/compiler @petrochenkov Is anyone keen to implement the stability PR for this (or create an issue with mentoring instructions)? It is a factor in one of the edition lints (#51043 (comment)) so is somewhat urgent.

[Centril]

Triage: no movement since 2018-07-04; cc @rust-lang/compiler

[nikomatsakis]

Mentoring instructions

This is a straightforward stabilization PR, so you can follow the instructions found in the forge page "So you want to stabilize a feature?".

In this case, the feature gate is: pattern_parentheses

[scottmcm]

Also, unused_patterns lint is still not updated; #51087 (comment)

[nikomatsakis]

@scottmcm ah, good catch, although I think it's not a blocker, as we can extend lints after the fact. Regardless, here are some tips for how to update that lint. The lint itself is declared here:

rust/src/librustc_lint/unused.rs

Lines 258 to 262 in 3bc2ca7

	declare_lint! {
	pub(super) UNUSED_PARENS,
	Warn,
	"`if`, `match`, `while` and `return` do not need parentheses"
	}

The meat of it is found in the check_expr callback here, which is invoked for every expression:

rust/src/librustc_lint/unused.rs

Line 326 in 3bc2ca7

fn check_expr(&mut self, cx: &EarlyContext, e: &ast::Expr) {

As you can see, it checks for various places where a lint would not be needed, such as in the body if an If, and then invokes this routine check_unused_patterns_core to issue a warning.

For patterns, I imagine we'll want to do something similar, but adding a check_pat method (this is the definition from the trait).

That said, I think this is quite a bit harder than the stabilization itself. If the person who handles this issue wants to do it, seems great, but if they are not familiar with the compiler, I think we could leave it out from the first PR, and then move this to a distinct issue to be added at some later time.

[ralexstokes]

i've been looking for a good way to contribute and this seems like something i could take a look at this weekend but if someone else wants to tackle this ahead of time let me know! -- i will probably skip the lint bit

[ralexstokes]

@nikomatsakis i followed the forge guide for PR #54497.

I've built the compiler locally and run on a test file incorporating the above sample: https://play.rust-lang.org/?gist=c8579523967ed072ea07cac191ee52cd&version=nightly&mode=debug&edition=2015

I ran all of the tests (./x.py test) and don't think I introduced any new problems.

Two questions:

1. Should we add more thorough tests that explicitly test for this pattern? There are tests which implicitly check some modes of behavior (e.g. /src/test/ui/run-pass/binding/pat-tuple-7.rs).

2. Any pointers on documentation? Seems like this should be updated: https://doc.rust-lang.org/reference/expressions/match-expr.html, but not sure what else makes sense right now.

This PR doesn't include the lint issue discussed above.

[nikomatsakis]

Filed #54538 for the unused-patterns lint.

[nikomatsakis]

@ralexstokes

Should we add more thorough tests that explicitly test for this pattern?

Well, more tests are always good. I see that I did not an absence of tests here. I'm not sure there are any particularly tricky scenarios here, but if you wanted to try to add parenthesis into various existing pattern tests, it seems like it would be good.

Any pointers on documentation? Seems like this should be updated: https://doc.rust-lang.org/reference/expressions/match-expr.html, but not sure what else makes sense right now.

Good question. I would think we would want to update the grammar on patterns, but I didn't see that one was defined in there. (cc @alercah @Havvy)

[Havvy]

Cc @ehuss

[nikomatsakis]

Removing P-high marker— though I would definitely appreciate some feedback from the @rust-lang/docs folk on what doc if any they feel is needed for this. Seems pretty minor though.

[Havvy]

The reference is updated. We'll also want to update TRPL though, I think.

[Centril]

Filed in the TRPL repo; closing therefore.