Uh oh!
There was an error while loading. Please reload this page.
Make anon params lint warn-by-default - #48309
Conversation
rust-highfive
commented
Feb 17, 2018
r? @estebank (rust_highfive has picked a reviewer for you, use r? to override) |
matklad
commented
Feb 18, 2018
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. |
mark-i-m
commented
Feb 18, 2018
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... |
estebank
commented
Feb 18, 2018
cc @rust-lang/lang |
nikomatsakis
commented
Feb 19, 2018
There was a problem hiding this comment.
Nit: error/warning messages conventionally start with lowercase.
nikomatsakis
commented
Feb 22, 2018
cc @rust-lang/lang -- I'd like to get some further thoughts on the right "stabilization schedule" here. |
est31
commented
Feb 22, 2018
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. |
matklad
commented
Feb 22, 2018
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) |
mark-i-m
commented
Feb 22, 2018
Total? Or that use anon params? |
mark-i-m
commented
Mar 5, 2018
Ping @rust-lang/lang |
cramertj
commented
Mar 5, 2018
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. |
nikomatsakis
commented
Mar 9, 2018
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. |
nikomatsakis
commented
Mar 12, 2018
Nominating to discuss in lang team meeting and make a decision on how to proceed. |
nikomatsakis
commented
Mar 22, 2018
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. |
rust-highfive
commented
May 23, 2018
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
estebank
commented
May 24, 2018
@mark-i-m you can rebase to master now and yes, squashing your commits would be best. |
mark-i-m
commented
May 24, 2018
Oh gosh... I messed up the rebase :/ Will fix and repush... |
mark-i-m
commented
May 24, 2018
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? |
bors
commented
May 25, 2018
☔ The latest upstream changes (presumably #50967) made this pull request unmergeable. Please resolve the merge conflicts. |
nikomatsakis
commented
May 25, 2018
@bors delegate=mark-i-m |
bors
commented
May 25, 2018
✌️ @mark-i-m can now approve this pull request |
nikomatsakis
commented
May 25, 2018
@mark-i-m r=me post rebase; I delegated to you so you should be able to instruct bors with |
mark-i-m
commented
May 27, 2018
@bors r=nikomatsakis |
bors
commented
May 27, 2018
📌 Commit 0e53b78 has been approved by |
bors
commented
May 27, 2018
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
bors
commented
May 28, 2018
☀️ Test successful - status-appveyor, status-travis |
Warn on anon params in 2015 edition cc #41686rust-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