Add support for Rust edition 2021.

[m-ou-se]

This adds support for ediiton = "2021".

Related rustc PR: rust-lang/rust#79576

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[alexcrichton]

Thanks for this! We'll probably want to hold off at least until the rustc PR is merged to avoid jumping the gun by accident, but one other question I have in the meantime is that we probably want this to be unstable until the edition is stabilized. Does rustc print an error if --edition 2021 is used on the stable channel? If so we can probably just defer to rustc's stability and avoid having a separate stability check in Cargo.

[m-ou-se]

Does rustc print an error if --edition 2021 is used on the stable channel?

It should, yes!

Current stable rustc:

$ rustc --edition=2021
error: argument for `--edition` must be one of: 2015|2018. (instead was `2021`)

'Stable' rustc with rust-lang/rust#79576:

$ rustc +stage1 --edition=2021
error: edition 2021 is unstable and only available for nightly builds of rustc.

[alexcrichton]

Sounds great! r=me for when the corresponding rust-lang/rust PR is approved as well

[m-ou-se]

Update: rust-lang/rust#79576 is approved, but waiting for the beta week to end. It should be merged 2021-01-01.

[m-ou-se]

rust-lang/rust#79576 has been merged.

[alexcrichton]

Great!

Could this also update this line?

cargo/src/cargo/ops/fix.rs

Lines 699 to 709 in 5463132

	fn next_edition(&self) -> &str {
	match self.enabled_edition.as_deref() {
	// 2015 -> 2018,
	None | Some("2015") => "2018",
	// This'll probably be wrong in 2020, but that's future Cargo's
	// problem. Eventually though we'll just add more editions here as
	// necessary.
	_ => "2018",
	}
	}

(or better yet refactor it so that the compiler warns us via enum-usage that the line needs to get updated)

Additionally do you know if lints are currently configured to enable this line yet --

cargo/src/cargo/ops/fix.rs

Lines 648 to 650 in 5463132

	if self.idioms && edition == "2018" {
	cmd.arg("-Wrust-2018-idioms");
	}

?

[m-ou-se]

Updated it to use the enum instead. Asking for an non-existent edition now gives an error instead of silently ignoring it like before.

I changed the self.idioms && edition == "2018" check to check for >= 2018 for now. Some (all?) of these lints (BARE_TRAIT_OBJECTS etc.) might become denied in edition 2021. Depending on how that all works out, this condition in cargo might need to be changed back to == later.

[m-ou-se]

The situation with cargo fix w.r.t. edition 2021 should get a bit more attention at some point. Now if you run it on a edition = "2018" crate, it'll tell you to switch back to 2015 so it can perform the edition fixes. But when 2021 is ready, it should be upgrading to 2021 instead, and can no longer warn the user for the mistake of placing edition = "2018" too soon in a 2015 → 2018 upgrade. Also, the error message for 2018 → 2021 with edition = "2021" should be different, as cargo will now tell the user to remote the edition = .. line instead of changing it back to edition = "2018".

(Also, should cargo fix be able to go directly from 2015 to 2021, or only through 2018?)

[alexcrichton]

Ok thanks for investigating! Seems like we should go ahead and land this and log the issues in a different location for handling later. Is there a central 2021 tracking issue we can log these bits on? Or should we create a new tracking issue in Cargo for these issues?

FWIW I'd imagine that we should probably stop printing an error and instead if you fix --edition when you're already in the latest edition it just says "success!" or something like that. For transitioning from any edition to any future edition, I think it depends on the compiler lint support, but I'd imagine that we'd probably only want to transition one edition at a time to avoid any possible weird bugs.

I also think that we'll probably want cargo fix --edition in the 2018 edition to print a better error for now other than "unknown lint" or "needs stable rustc suport", we may want a bit in Cargo saying somewhere what the latest stable edition is so if you fix --edition in the latest stable edition then nothing happens (or Cargo just prints success or something like that)

[m-ou-se]

Is there a central 2021 tracking issue we can log these bits on?

Nope, but there's a hackmd in which we're trying to collect everything around the 2021 edition. Eventually it should all be tracked in proper github issues collected on the 2021 project board, so let's just open an issue on this repository to keep track of this.

Edit: I've opened that issue, added it to the document and the project board.

[alexcrichton]

@bors: r+

👍 that looks perfect to me, thanks!

[bors]

📌 Commit bc0c820 has been approved by alexcrichton

[bors]

⌛ Testing commit bc0c820 with merge e427d01b4fab3b004b42446e607861516f67a92e...

[bors]

💔 Test failed - checks-actions

[alexcrichton]

@bors: retry

[bors]

⌛ Testing commit bc0c820 with merge 3bb0968...

[bors]

☀️ Test successful - checks-actions
Approved by: alexcrichton
Pushing 3bb0968 to master...