Remove edition warning in cargo script w/o frontmatter

[nixpulvis]

Problem

From #12207 (comment)

I don't think a warning should be printed on a script without any frontmatter.

fn main() {
    println!("hello world");
}

Gives output:

warning: `package.edition` is unspecified, defaulting to `2024`
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.00s
     Running `/Users/nate/.cargo/build/cd/32beff75ef4495/target/debug/foo`
hello world

Proposed Solution

Do not emit warning when no edition is specified for a cargo script. Defaulting to the latest edition is a perfectly reasonable default, and is what anyone would expect. Warnings on bare rust scripts without frontmatter are unnecessary noise for users who may not care about edition stability. If you care about stability, you can still specify it easily with frontmatter.

Notes

N/A

[epage]

From #12207 (comment)

We are trying to balance

• overhead in writing modern code (i.e. don't want to default to 2015 edition)

• ensure long lived scripts don't break on new editions

I doubt this will change at this point but re-litigating this part of the rfc likely should be in a dedicated issue rather than taking up this thread.

[epage]

If you care about stability, you can still specify it easily with frontmatter.

How are people to know that the edition is not "2015" (like Cargo.toml) and that they need to pin the edition?

[c-git]

I think 2015 edition would be less surprising. Same as normal rust create is what I would expect. I also think upgrading and then the script breaking would be surprising. I think there is a way to hide warnings (feels bad saying it). But that might be better than just an implicit hidden trap. I don't think it's very discoverable to know you need to worry about the edition if it's hidden.

[dpc]

There's an impossible to solve conflict here between not needing to have edition = and potentially not breaking the script once upstream Rust adds new edition.

Defaulting to 2015 in Rust/cargo was necessary, given how much code was already there before edition = was even a thing. But realistically, the ecosystem as whole can't forever default to the original edition 2015. Which means in practice any Rust code, to not have a possibility of breaking in the future, needs to have an externally specified edition somewhere.

So it seems to me any reasonable cargo-script need to have a frontmatter and edition = in it, just like any reasonable Rust cargo crate. That's just how things are and the "convenience" of not needing it is just a little UX bandaid. And realistically, given the small-stdlib philosophy, usability of cargo-scripts that don't even need a single dependency is minimal.

So my opinion on it is:

• Print warning by default.
• Have a env var that disables that warning. People that really hate it, or where it really breaks their use case can set it in their shell permanently and largely forget about it.
• Default to current to latest edition, because ... defaulting to 11 years old edition is counterproductive.

[nixpulvis]

I can see why being consistent with the default for rust create is compelling... but I really believe that if someone cares about stability, they should add the frontmatter.

I'd just like a clean and simple way to execute rust with cargo script with as little boilerplate as possible. Being able to use the latest edition in this situation would be nice.

I don't personally see upgrading a tool breaking scripts as surprising at all. This would be true of many other scripting languages and tools. If you care, we still support locking it down in the frontmatter.

The main concern here is providing the warning to everyone so people are aware of this feature, which to me is not a good use of a warning. Esspecially when the remady requires extra boilerplate in a tool (cargo script) enitrely designed to remove boilerplate. I could always make a new cargo directory and all that, but I use cargo script when I want to quickly write an executable.

[epage]

Note that if Cargo defaults to edition = "2015", users would see a warning for a different reason:

$ cat Cargo.toml
[package]
name = "cargo-edition"
version = "0.1.0"

[dependencies]

$ cargo check
warning: no edition set: defaulting to the 2015 edition while the latest is 2024
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.00s

[epage]

Have a env var that disables that warning. People that really hate it, or where it really breaks their use case can set it in their shell permanently and largely forget about it.

Our overall goal is to move as many hard coded warnings to lints and there is no plan for lints to be controllable through the environment, we don't just control cargo through the environment but through config, and I would be reticent to special case this one lint.

That said, I've proposed the idea of cargo offering advice that is config controllable (#16247), inspired by git.

[nixpulvis]

I would be happy with a user config for advice to suppress the message about unspecified edition.

I understand how this plays into the edition stability story, so I'm sympathetic to the default message. Just for me personally, I am quite aware of and comfortable with the concept of editions and don't need to see a warning when I run a script. Worst case, I forget to add an edition, and have to go back later and specify it.

It will be a little confusing to have cargo script default to the latest edition, while cargo itself defaults to 2015 when no edition is specified, but personally I'd rather have cargo default to the latest. That would itself be an edition breakage, so we're kinda stuck with that, since we didn't have editions when cargo's toml was defined.

[0e4ef622]

Would it make sense to have a command that adds the frontmatter to an existing script? That could be suggested as part of the warning.

[epage]

The goal is eventually cargo fix will be able to apply suggestions from cargo warnings we'd add a suggestion to this.