feat(toml): Warn on unset Edition

[epage]

What does this PR try to resolve?

On Internals, the idea came up for warning on unset Edition.

Besides helping people who forget to set the Edition, this creates symmetry between Cargo.toml and cargo scripts (#12207). While the default is different in each case, we are making the default obvious and guiding people away from it.

How should we test and review this PR?

There are separate commits for adding tests (and refactors) so the changes in behavior will be more obvious

Additional information

This builds on

• fix(rustc): Always pass --edition to rustc #13499
• test: Make edition explicit in packages #13504

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[weihanglo]

Should we call out which package it is? There might be a workspace containing tons of members.

[epage]

Looks like its done for us:

                        // In a workspace, it can be confusing where a warning
                        // originated, so include the path.
                        format!("{}: {}", path.display(), warning.message)

The other warnings I looked at do not mention the package which is why I dug into it to find that code. The test case must be only for a single package so it gets elided.

[weihanglo]

Given edition 2015 is quite old, I assume most people won't be flooded with this error messages. If it turns out to be a real problem, we can consider revert.

@bors r+

[bors]

📌 Commit 768c70a has been approved by weihanglo

It is now in the queue for this repository.

[bors]

⌛ Testing commit 768c70a with merge f772ec0...

[bors]

☀️ Test successful - checks-actions
Approved by: weihanglo
Pushing f772ec0 to master...

[taiki-e]

Is it possible to silence this warning to the workspace contains a crate that have rust-version < 1.31?

I don't think this warning is useful at all for crates with MSRV lower than 1.31, as adding the edition will break the MSRV.

[weihanglo]

I don't think this warning is useful at all for crates with MSRV lower than 1.31, as adding the edition will break the MSRV.

That sounds reasonable. However the edition field predates rust-version. How can Cargo determine MSRV when there is no rust-version set?

[taiki-e]

However the edition field predates rust-version. How can Cargo determine MSRV when there is no rust-version set?

rust-version field is just ignored on old cargo. This means a crate with old MSRV can have rust-version field. For example: https://github.com/serde-rs/serde/blob/v1.0.179/serde/Cargo.toml#L14

[weihanglo]

rust-version field is just ignored on old cargo.

Isn't this the same as setting edition = "2015" for those package on old caroges? Also, does it make sense that a package supports old MSRV than its edition settings? For example the author only uses Cargo-specific edition features but not Rust compiler's.

Yet I understand that Cargo should be smarter to infer edition for those on old MSRV. Need to think more on it.

[taiki-e]

Isn't this the same as setting edition = "2015" for those package on old caroges?

edition = "2015" causes an error on some old versions (e.g., 1.27). See also an example in "Caveats" section in rust-lang/rust-clippy#6324.

$ cat Cargo.toml 
[package]
name = "repro"
version = "0.1.0"
edition = "2015"

$ cargo +1.27 build
error: failed to parse manifest at `/Users/taiki/projects/tmp/repro/Cargo.toml`

Caused by:
  editions are unstable

Caused by:
  feature `edition` is required

this Cargo does not support nightly features, but if you
switch to nightly channel you can add
`cargo-features = ["edition"]` to enable this feature

Most previously unstable fields have similar properties (e.g., #10954), but the rust-version field is special and is implemented in a way that it does not cause such errors in any version.

https://doc.rust-lang.org/cargo/reference/manifest.html#the-rust-version-field

The first version of Cargo that supports this field was released with Rust 1.56.0. In older releases, the field will be ignored, and Cargo will display a warning.

---

does it make sense that a package supports old MSRV than its edition settings?

(Assuming you are talking about a crate like: MSRV is 1.20 but the edition is 2018.)
I don't think it makes sense because the only time it doesn't cause an error is when building with a very old cargo (pre-1.27), and it is just ignored.

Also, specifying MSRV older than the edition in the rust-version field causes an error.

https://doc.rust-lang.org/cargo/reference/manifest.html#the-rust-version-field

The rust-version must be equal to or newer than the version that first introduced the configured edition.