Experimental feature postfix match by RossSmyth · Pull Request #121619 · rust-la...
source link: https://github.com/rust-lang/rust/pull/121619
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Experimental feature postfix match #121619
Conversation
Contributor
This has a basic experimental implementation for the RFC postfix match (rust-lang/rfcs#3295, #121618). Liaison is @scottmcm with the lang team's experimental feature gate process.
This feature has had an RFC for a while, and there has been discussion on it for a while. It would probably be valuable to see it out in the field rather than continue discussing it. This feature also allows to see how popular postfix expressions like this are for the postfix macros RFC, as those will take more time to implement.
It is entirely implemented in the parser, so it should be relatively easy to remove if needed.
This PR is split in to 5 commits to ease review.
- The implementation of the feature & gating.
- Add a MatchKind field, fix uses, fix pretty.
- Basic rustfmt impl, as rustfmt crashes upon seeing this syntax without a fix.
- Add new MatchSource to HIR for Clippy & other HIR consumers
Collaborator
|
rustbot has assigned @petrochenkov. Use r? to explicitly pick a reviewer |
added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
labels
Collaborator
|
Some changes occurred in src/tools/rustfmt cc @rust-lang/rustfmt Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
This comment has been minimized.
Contributor
Author
|
UI tests need to be culled |
This comment has been minimized.
The rustfmt team prefers that support for experimental features be added in a PR to the rust-lang/rustfmt repo. I've proposed an alternative set of changes that should prevent rustfmt from removing the experimental postfix expressions, but not apply formatting to it.
Comment on lines
+173 to +174
ast::ExprKind::Match(ref cond, ref arms, kind) => { |
||
rewrite_match(context, cond, arms, shape, expr.span, &expr.attrs, kind) |
Contributor
Given that the postfix match is an experimental feature I'd prefer not to add formatting support in this PR. For now I think it makes sene to add just enough support so that rustfmt doesn't completely remove the postfix match.
I think the following changes would achieve that.
match kind {
MatchKind::Prefix => rewrite_match(context, cond, arms, shape, expr.span, &expr.attrs),
MatchKind::Postfix => {
// experimental feature postfix match (link to RFC)
Some(context.snippet(expr.span).to_owned())
}
}cc: @calebcartwright
Contributor
Author
That is what I did originally and iirc it caused rustfmt to crash.
Contributor
The only way I can think for context.snippet(expr.span).to_owned() to crash is if the expr.span isn't valid, but that seems unlikely. You could also try returning None from the MatchKind::Postfix match arm.
I actually don't have any concerns with the formatting implementation proposed here as this is rather trivial syntactically, a reasonable initial formatting, and in accordance with the style guide policy on nightly-only/experimental syntax.
the more intriguing part for me was the mention of it "crashing", the details of which I'd be interested in seeing (though that could be shared with us separately in Zulip)
Contributor
Author
Some sort of panic occurred. I'll try to replicate it when I work on this and post it on Zulip. Probably won't be until Friday or Saturday though.
Contributor
Author
Ok, here's a branch with the panic: https://github.com/RossSmyth/rust/tree/rustfmt_test_panic
It be may as designed? Looking at it again after just running x.py test rustfmt
Ran 589 system tests.
assertion `left == right` failed: 1 system tests failed
left: 1
right: 0
Failed to join a test thread: Any { .. }
failures:
test::system_tests
test result: FAILED. 171 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; finished in 7.15sThere are two panics that occur.
Fails with left == right failed: 1 idempotent tests failed
Fails with panicked at src\\tools\\rustfmt\\src\\test\\mod.rs:76:10:\nFailed to join a test thread: Any { .. }
Is it designed to just panic if a test fails? It also dumps a pretty large JSON object out.
Collaborator
|
Some changes occurred in match checking cc @Nadrieril |
This comment has been minimized.
Contributor
Author
|
Two new commits:
I'm not sure if the second commit is needed or desired. There is more worked needed, but as far as I can tell it doesn't break clippy. Since there are many other MatchSources, clippy guards against the other kinds well. So in the end it results in Clippy ignoring postfix match expression and not emitting any lints. A quick |
Contributor
Author
|
Hmm I'm not sure why this fails in CI. It works on my computer. It looks like ui_tests isn't normalizing the test paths for some reason. Which is strange as every other Clippy UI test uses |
Contributor
There are too many tests in |
added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
labels
Contributor
Author
I am aware of that. I am talking about the Clippy UI test failure. |
This comment has been minimized.
This comment has been minimized.
Contributor
|
r=me on the implementation. |
Contributor
Author
|
@rustbot ready |
Collaborator
|
Failed to set assignee to
|
added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
labels
Member
|
Hello fellow lang folks! I'm not sure exactly what the process is on our side to approve this, but since it's not a one-way door let's try a poll: @rfcbot poll T-lang Are you ok with an experimental implementation of postfix match in nightly? I'm not planning on waiting for full checkboxes, since we can always revert the nightly implementation if necessary, but I want to give an opportunity for folks to raise objections just in case. |
|
Team member @scottmcm has asked teams: T-lang, for consensus on:
|
added the S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). label
added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label
Member
|
@bors r=petrochenkov |
added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label).
labels
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Successfully merging this pull request may close these issues.
None yet
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK