Rename the 2018 edition lint names by alexcrichton · Pull Request #50620 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation10 Commits1 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
rust_2018_breakage->rust_2018_compatibility- the lint for ensuring
that your code, in the 2015 edition, is compatible with the 2018 edition's
semantics. This is required to pass before you enable the 2018 edition.rust_2018_migration->rust_2018_idioms- the lint for writing idiomatic
code after you've already enabled the 2018 edition
rust_2018_breakage->rust_2018_compatibility- the lint for ensuring that your code, in the 2015 edition, is compatible with the 2018 edition's semantics. This is required to pass before you enable the 2018 edition.rust_2018_migration->rust_2018_idioms- the lint for writing idiomatic code after you've already enabled the 2018 edition
(rust_highfive has picked a reviewer for you, use r? to override)
What about lints that can change 2015 code to 2015 code while updating certain idioms? For example, I think there's a few features (maybe dyn Trait?) which will work in the 2015 edition, and authors might want to have rust_2018_idioms mean different things depending on the current edition: in the 2015 edition these are non-2018 edition dependent lints, and in 2018 they are all the lints, both those dependent on the edition and not.
Those lints can fit in either category, I don't think there are strong opinions on which category they belong in.
@aturon had written a doc about this but I can't find it rn
@Mark-Simulacrum I'd personally expect lints like that to get turned on by default over time in the sense that yeah we'd even want 2015 (and really encourage 2018) code to migrate. I may be alone in the opinion of turning these eventually on by default though!
For the most part these lints are actually internal implementation details that others won't access. Rather cargo-fix will translate --prepare-for 2018 to -W rust-2018-compatibility and --edition 2018 would translate to -W rust-2018-idioms (or something like that). In general users won't have to look too closely at these names.
📌 Commit d636aec has been approved by nikomatsakis
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.
labels
@bors: p=1
prioritizing for edition preview
bors added a commit that referenced this pull request
Rename the 2018 edition lint names
rust_2018_breakage->rust_2018_compatibility- the lint for ensuring that your code, in the 2015 edition, is compatible with the 2018 edition's semantics. This is required to pass before you enable the 2018 edition.rust_2018_migration->rust_2018_idioms- the lint for writing idiomatic code after you've already enabled the 2018 edition
killercup added a commit to killercup/rustfix that referenced this pull request
killercup added a commit to killercup/rustfix that referenced this pull request
Labels
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.