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

Rename the 2018 edition lint names #50620

Merged
merged 1 commit into from
May 11, 2018

Conversation

alexcrichton
Copy link
Member

  • 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
Copy link
Collaborator

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 10, 2018
@Mark-Simulacrum
Copy link
Member

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.

@Manishearth
Copy link
Member

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

@aturon
Copy link
Member

aturon commented May 10, 2018

@alexcrichton
Copy link
Member Author

@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.

@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented May 10, 2018

📌 Commit d636aec has been approved by nikomatsakis

@bors bors 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. labels May 10, 2018
@aturon
Copy link
Member

aturon commented May 11, 2018

@bors: p=1

prioritizing for edition preview

@bors
Copy link
Contributor

bors commented May 11, 2018

⌛ Testing commit d636aec with merge 41707d8...

bors added a commit that referenced this pull request May 11, 2018
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
@bors
Copy link
Contributor

bors commented May 11, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 41707d8 to master...

@bors bors merged commit d636aec into rust-lang:master May 11, 2018
killercup added a commit to killercup/rustfix that referenced this pull request May 13, 2018
Fixes usage on a nightly after rust-lang/rust#50620
killercup added a commit to killercup/rustfix that referenced this pull request May 13, 2018
Fixes usage on a nightly after rust-lang/rust#50620
@alexcrichton alexcrichton deleted the change-names-again branch June 29, 2018 19:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants