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

Add more diagnostics to smooth edition transition #5824

Merged
merged 2 commits into from
Jul 31, 2018

Conversation

alexcrichton
Copy link
Member

This commit adds two diagnostics in particular to ease the transition into the
2018 edition. The current transition process is pretty particular and must be
done carefully, so let's try to automate things to make it as painless as
possible! Notably the new diagnostics are:

  • If you cargo fix --prepare-for 2018 a crate which already has the 2018
    edition enabled, then an error is generated. This is because the compiler
    can't prepare for the 2018 edition if you're already in the 2018 edition, the
    lints won't have a chance to fire. You can only execute --prepare-for 2018
    over crates in the 2015 edition.

  • If you cargo fix --prepare-for 2018 and have forgotten the
    rust_2018_preview feature, a warning is issued. The lints don't fire unless
    the feature is enabled, so this is intended to warn in this situation to
    ensure that lints fire as much as they can.

After this commit if cargo fix --prepare-for exits successfully with zero
warnings then crates should be guaranteed to be compatible!

Closes #5778

@rust-highfive
Copy link

r? @matklad

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

@alexcrichton alexcrichton force-pushed the careful-transition branch 2 times, most recently from 30488b1 to e4f447b Compare July 30, 2018 22:39
@alexcrichton
Copy link
Member Author

@bors: r+

@bors
Copy link
Collaborator

bors commented Jul 30, 2018

📌 Commit e4f447bfdce4da79c4737c11a1531a50496387a3 has been approved by alexcrichton

@bors
Copy link
Collaborator

bors commented Jul 30, 2018

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout careful-transition (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self careful-transition --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
Auto-merging tests/testsuite/fix.rs
CONFLICT (content): Merge conflict in tests/testsuite/fix.rs
Auto-merging src/cargo/ops/fix.rs
Auto-merging src/cargo/core/compiler/mod.rs
Automatic merge failed; fix conflicts and then commit the result.

The previous heuristic for fixing packages was to fix all packages in a
workspace, aka those with path dependencies. Instead this commit switches cargo
over to only fixing the "primary" package, or those requested on the command
line or implicitly via cwd.

This will later help us identify which packages are being targeted so we can
provide tailored warnings and errors for mixed up transition steps.
@alexcrichton
Copy link
Member Author

@bors: r+

@bors
Copy link
Collaborator

bors commented Jul 30, 2018

📌 Commit 438e240ee3cf324ffcc8f5565a63d940ea336886 has been approved by alexcrichton

@bors
Copy link
Collaborator

bors commented Jul 30, 2018

⌛ Testing commit 438e240ee3cf324ffcc8f5565a63d940ea336886 with merge 47829c0348b83c236339b7fa2353a907e3d52fa1...

@alexcrichton
Copy link
Member Author

@bors: r+

@bors
Copy link
Collaborator

bors commented Jul 30, 2018

📌 Commit d7f091e36a77b05b729e293041a7bb0c81277ccb has been approved by alexcrichton

@bors
Copy link
Collaborator

bors commented Jul 30, 2018

⌛ Testing commit d7f091e36a77b05b729e293041a7bb0c81277ccb with merge 53c351e98c71fcc6b4184da62bc9b4bdc7e3ad9a...

@bors
Copy link
Collaborator

bors commented Jul 30, 2018

💔 Test failed - status-travis

This commit adds two diagnostics in particular to ease the transition into the
2018 edition. The current transition process is pretty particular and must be
done carefully, so let's try to automate things to make it as painless as
possible! Notably the new diagnostics are:

* If you `cargo fix --prepare-for 2018` a crate which already has the 2018
  edition enabled, then an error is generated. This is because the compiler
  can't prepare for the 2018 edition if you're already in the 2018 edition, the
  lints won't have a chance to fire. You can only execute `--prepare-for 2018`
  over crates in the 2015 edition.

* If you `cargo fix --prepare-for 2018` and have forgotten the
  `rust_2018_preview` feature, a warning is issued. The lints don't fire unless
  the feature is enabled, so this is intended to warn in this situation to
  ensure that lints fire as much as they can.

After this commit if `cargo fix --prepare-for` exits successfully with zero
warnings then crates should be guaranteed to be compatible!

Closes rust-lang#5778
@alexcrichton
Copy link
Member Author

@bors: r+

@bors
Copy link
Collaborator

bors commented Jul 31, 2018

📌 Commit fa7a387 has been approved by alexcrichton

@bors
Copy link
Collaborator

bors commented Jul 31, 2018

⌛ Testing commit fa7a387 with merge 9bbab73...

bors added a commit that referenced this pull request Jul 31, 2018
Add more diagnostics to smooth edition transition

This commit adds two diagnostics in particular to ease the transition into the
2018 edition. The current transition process is pretty particular and must be
done carefully, so let's try to automate things to make it as painless as
possible! Notably the new diagnostics are:

* If you `cargo fix --prepare-for 2018` a crate which already has the 2018
  edition enabled, then an error is generated. This is because the compiler
  can't prepare for the 2018 edition if you're already in the 2018 edition, the
  lints won't have a chance to fire. You can only execute `--prepare-for 2018`
  over crates in the 2015 edition.

* If you `cargo fix --prepare-for 2018` and have forgotten the
  `rust_2018_preview` feature, a warning is issued. The lints don't fire unless
  the feature is enabled, so this is intended to warn in this situation to
  ensure that lints fire as much as they can.

After this commit if `cargo fix --prepare-for` exits successfully with zero
warnings then crates should be guaranteed to be compatible!

Closes #5778
@alexcrichton alexcrichton added this to the Edition Preview 2 milestone Jul 31, 2018
@bors
Copy link
Collaborator

bors commented Jul 31, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 9bbab73 to master...

@bors bors merged commit fa7a387 into rust-lang:master Jul 31, 2018
@alexcrichton alexcrichton deleted the careful-transition branch August 1, 2018 14:05
@ehuss ehuss mentioned this pull request Jun 22, 2019
bors added a commit that referenced this pull request Jun 22, 2019
Update some fix comments.

- Primary handling changed in #5824.
- cargo_as_rustc_wrapper changed in #6759.
@ehuss ehuss modified the milestones: Edition Preview 2, 1.29.0 Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

cargo fix: Prevent fixing in mixed up transition steps
5 participants