Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make future-compat lint match_of_unit_variant_via_paren_dotdot deny by default #31757

Merged
merged 1 commit into from
Feb 21, 2016

Conversation

petrochenkov
Copy link
Contributor

This warning was introduced on Nov 28, 2015 and got into 1.6 stable, it was later requalified from a hardwired warning to a warn-by-default lint.
If this patch is landed soon enough, then match_of_unit_variant_via_paren_dotdot will get into 1.8 stable as a deny-by-default lint.
My intention is to turn it into a hard error after March 3, 2016, then it will hit stable at 1.9.

r? @nikomatsakis
cc @pnkfelix

@nikomatsakis nikomatsakis added I-nominated T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Feb 18, 2016
@nikomatsakis
Copy link
Contributor

Nominating for discussion in the @rust-lang/lang team mtg today. This makes sense, but it always seems like a good idea to double check before we go on making our deprecations more aggressive. This is also a @rust-lang/core issue (@brson may have particular opinions here).

@nikomatsakis
Copy link
Contributor

We discussed this in @rust-lang/lang and decided it makes sense to go forward with this as proposed. There is still some general teeth gnashing (at least on my part) that we now lack any generic way to write a pattern that says "this variant and I don't care what fields are there", but the feeling is that the distinctions around () vs {} can be confused, and so being more specific should help. And anyway we already started down this road. (@pnkfelix and I have a secret plan to introduce Foo { ... } as the "one true" pattern that can be used with any declaration style, but that'd clearly be the topic of an RFC.)

@nikomatsakis nikomatsakis added relnotes Marks issues that should be documented in the release notes of the next release. and removed I-nominated labels Feb 19, 2016
@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Feb 19, 2016

📌 Commit e950659 has been approved by nikomatsakis

@petrochenkov
Copy link
Contributor Author

@pnkfelix and I have a secret plan to introduce Foo { ... } as the "one true" pattern that can be used with any declaration style, but that'd clearly be the topic of an RFC

FYI, I started writing such an RFC about an hour ago.
Coincidence? I don't think so!

@brson
Copy link
Contributor

brson commented Feb 20, 2016

+1

@bors
Copy link
Contributor

bors commented Feb 20, 2016

⌛ Testing commit e950659 with merge c894ff6...

bors added a commit that referenced this pull request Feb 20, 2016
This warning was introduced on Nov 28, 2015 and got into 1.6 stable, it was later requalified from a hardwired warning to a warn-by-default lint.
If this patch is landed soon enough, then `match_of_unit_variant_via_paren_dotdot` will get into 1.8 stable as a deny-by-default lint.
My intention is to turn it into a hard error after March 3, 2016, then it will hit stable at 1.9.

r? @nikomatsakis
cc @pnkfelix
@alexcrichton
Copy link
Member

@bors: retry force

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Marks issues that should be documented in the release notes of the next release. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants