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

More helpful error message for unsupported editions: display the required rust-version #15305

Open
tarcieri opened this issue Mar 13, 2025 · 3 comments
Labels
A-manifest Area: Cargo.toml issues C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.

Comments

@tarcieri
Copy link

Problem

When cargo encounters an unsupported edition, the error message it displays isn't actionable, where the action in this case is to upgrade cargo/rustc to 1.85 or newer:

Caused by:
  feature `edition2024` is required

  The package requires the Cargo feature called `edition2024`, but that feature is not stabilized in this version of Cargo (1.81.0 (2dbb1af80 2024-08-20)).

Proposed Solution

In the event an edition is unsupported, It would be more helpful if cargo printed the standard error for an out-of-date rust version by extracting package.rust-version when specified:

error: rustc 1.81.0 is not supported by the following package:
  [email protected] requires rustc 1.85

Notes

No response

@tarcieri tarcieri added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage. labels Mar 13, 2025
@epage epage added the A-manifest Area: Cargo.toml issues label Mar 13, 2025
@epage
Copy link
Contributor

epage commented Mar 13, 2025

This would be a great improvement!

I'm unsure if we should completely mask the current error or extend it. This would be especially important for people passing --ignore-rust-versions who would then feel like its not being ignored.

On the implementation side, is it safe to assume that if we hit the feature gate and a package.rust-version is present, that the package is newer than the current toolchain? I've not dealt much with nightly-only packages. The challenge with checking if package.rust-version is newer than rustc -V is that we want to cache that call and we currently only cache that call in the workspace, so we need to know the workspace. However, the manifest parsing code is the same before we've discovered the workspace and after and trying to tunnel in a maybe-workspace feels weird. Maybe we could cache it in GlobalContext once we first discover it and then manifest parsing could use it if its present.

Or we could just add a

help: [email protected] requires rustc 1.85

and not state one way or the other whether that is the problem, just additional context.

@weihanglo
Copy link
Member

How do old toolchains know a new Rust Edition requires a certain toolchain version?

@epage
Copy link
Contributor

epage commented Mar 13, 2025

We wouldn't but we may know a package's MSRV which can work just as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-manifest Area: Cargo.toml issues C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

3 participants