-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 anon params lint warn-by-default #48309
Conversation
r? @estebank (rust_highfive has picked a reviewer for you, use r? to override) |
I personally don't feel that we need to rush this into the new epoch. What about turning the warning one in the new epoch instead, and then turning it into a hard error in the latter epoch? Actually, if the epoch includes some drastic change with significant amount of churn, like the rethinking of absolute paths, I would prefer even to not turn a warning on for this very first epoch. It seems interesting to make the very first epoch as small as possible in terms of the actual changes, gain experience with epochs as a thing, and postpone more churn-prone changes to latter epochs. |
Hmm... That's definitely an important consideration. I guess the question is do we want to minimize trivially rustfix-able changes as much as more substantial ones like path changes? One could also argue that by warning now, we would minimize churn in the new epoch... |
cc @rust-lang/lang |
src/librustc_lint/builtin.rs
Outdated
@@ -627,7 +627,8 @@ impl EarlyLintPass for AnonymousParameters { | |||
if ident.node.name == keywords::Invalid.name() { | |||
cx.span_lint(ANONYMOUS_PARAMETERS, | |||
arg.pat.span, | |||
"use of deprecated anonymous parameter"); | |||
"Anonymous parameters are deprecated and will be \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: error/warning messages conventionally start with lowercase.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
cc @rust-lang/lang -- I'd like to get some further thoughts on the right "stabilization schedule" here. |
I don't think this particular change is churn prone, as in it doesn't affect many crates. We could turn it into an error though and make a crater run but I doubt the number of crates would be large. I think a good idea would be to put this lint into the "pre-epoch" group of lints (is there such a group yet?) but otherwise to keep it allow by default. On the epoch switch, we can then turn it cleanly into a new error. |
FWIW, we've already measured that in the RFC (using IntelliJ and not crater :) ) At that time, 416 out of 5560 crates were affected (and, wow, we now have 14115 crates) |
Total? Or that use anon params? |
Ping @rust-lang/lang |
This change seems fine to me, although this seems like more of a policy issue than a language design issue. IMO we should feel free to introduce warnings whenever we want, rather than waiting to bundle a bunch of new warnings with the next epoch. |
We've been reviewing general epoch policy, and it's worth considering how this would fit in (cc #48796). The basic idea is that we divide changes into two categories:
In Rust 2015 code, these two errors are treated differently:
I think that in general we prefer to avoid hard errors in the new epoch. Considered on the merits, it feels like this error should probably be an "idiom shift" sort of lint for the new epoch -- there is no particular reason we can't recover from it, given that we must continue parsing anyhow. OTOH, I'm pretty sure we can get away with making it a hard error. Still, I think that my vote would be for idiom shift. |
Nominating to discuss in lang team meeting and make a decision on how to proceed. |
We discussed this in the @rust-lang/lang meeting but didn't reach a firm conclusion. I think I will start an internals thread to discuss this and other similar questions about how aggressive to be in the Rust 2018 transition. Personally, I lean towards saying that in the Rust 2018 edition we can classify this as a "unforced deprecation" -- and therefore start warning/linting, rather than giving a hard error right away. |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Fix span for type-only arguments Currently it points to the comma or parenthesis before the type, which is broken cc @mark-i-m this is what broke rust-lang#48309 r? @estebank
@mark-i-m you can rebase to master now and yes, squashing your commits would be best. |
Oh gosh... I messed up the rebase :/ Will fix and repush... |
Ok, much better. Also, this passed travis after I rebased on master but before I squashed, so it should pass now too. @nikomatsakis Time for one last review? |
☔ The latest upstream changes (presumably #50967) made this pull request unmergeable. Please resolve the merge conflicts. |
@bors delegate=mark-i-m |
✌️ @mark-i-m can now approve this pull request |
@mark-i-m r=me post rebase; I delegated to you so you should be able to instruct bors with |
@bors r=nikomatsakis |
📌 Commit 0e53b78 has been approved by |
Make anon params lint warn-by-default This is intended as a followup on anonymous parameters deprecation. Cross-posting from #41686: > After having read a bit more of the discussion that I can find, I propose a more aggressive deprecation strategy: > - We make the lint warn-by-default as soon as possible > - We make anon parameters a hard error at the epoch boundary cc @matklad @est31 @aturon
☀️ Test successful - status-appveyor, status-travis |
Warn on anon params in 2015 edition cc #41686 rust-lang/rfcs#2522 cc @Centril @nikomatsakis TODO: - [x] Make sure the tests pass. - [x] Make sure there is rustfix-able suggestion. Current plan is to just suggest `_ : Foo` - [x] Add a rustfix ui test. EDIT: It seems I already did the last two in #48309
This is intended as a followup on anonymous parameters deprecation.
Cross-posting from #41686:
cc @matklad @est31 @aturon