It is impossible to compile any individual Edition 2021 package in a workspace using Cargo 2021 if there is even one Edition 2024 package

[nik-rev]

Problem

Picture the following Cargo Workspace, with 2 packages:

• Package 1 is Edition 2021
• Package 2 is Edition 2024

It is impossible to compile just Package 1 using Cargo 1.75 (or any version where Edition 2024 isn't available).

If you try: Cargo 1.75 attempts to validate Package 2's manifest, sees edition = "2024" and refuses to proceed - even though we don't care about Package 2 at all.

Example workflow which is broken by this limitation

• You have several crates in a workspace, all of which have rust-version = "1.75". This is our MSRV

• But you actually use a nightly Rust toolchain while developing these crates - to gain latest features of rust-analyzer, latest clippy/rustc lints and use nightly rustfmt options like formatting code in doc comments.

• You have a separate crate tests that includes integration tests of all the packages in your workspace.

  Because this crate isn't shipped with your other libraries, you want to use nightly Rust and Edition 2024

  You want this crate to be part of the workspace. We don't just want to exclude it. We may want to e.g. inherit lints and packages from the workspace manifest.

• In your CI, you want to build all those other crates using cargo +1.75 to ensure they build using your MSRV. Here is where the problem is. This step is impossible to do.

Example workspace

This workspace illustrates the example above

Cargo.toml: Workspace manifest

[workspace]
members = ["foo", "foo_tests"]

foo/Cargo.toml: Our main library. MSRV is 1.75

[package]
name = "foo"
version = "0.1.0"
edition = "2021"
rust-version = "1.75.0"

foo_tests/Cargo.toml: Tests for our library. Uses nightly #[feature]s and edition 2024 because we're not building the tests and shipping them with the library. Should be OK

[package]
name = "foo_tests"
version = "0.1.0"
edition = "2024"

Trying to compile just the package foo is not possible:

> cargo +1.75 build --package foo
error: failed to load manifest for workspace member `foo_tests`

Caused by:
  failed to parse manifest at `foo_tests/Cargo.toml`

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.75.0 (1d8b05cdd 2023-11-20)).
  Consider trying a newer version of Cargo (this may require the nightly release).
  See https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#edition-2024 for more information about the status of this feature.

We don't actually care about foo_tests for this purpose, yet Cargo still tries to verify its manifest.

There should be some way to ignore foo_tests for this purpose.

Proposed Solution

No response

Notes

No response

[epage]

Maybe I'm wrong but I see this as less of an issue with Editions specifically and more of an issue with multiple MSRVs, particularly when using newer Cargo features. We run into this with the Cargo workspace and have to limit our use of Cargo features to those that match our lowest MSRV.

I believe a workaround is cargo hack's --no-private flag which will remove unpublished packages from manifests.

One of the challenges in addressing this is that dependency resolution for a workspace is dependent on all workspace members which means we have to load all workspace members.

There are also occasionally requests that rely on inferring information for a package from other workspace members (e.g. #11133) though that adds a layer of complexity that makes things unlikely.

If we limit ourselves to dependency resolution,

• with RFC: Give users control over feature unification rfcs#3692 there was discussion of allowing per-package lockfiles.
• If we could have a variant of --locked that is more of "error if something is missing but don't worry about there being extra content" then we could skip loading of workspace members in that case
• Nested workspaces #5042 might be a way to solve this though that is stuck in finding a design that works

The first two would have to change our assumption in Cargo that all workspace members are always loaded. This even affects how we parse lockfiles because path dependencies are only stored in the lockfile by name which is then resolved on lockfile load by walking all workspace members and their path dependencies.

[iampi31415]

Isn't it useful for you to use:

[workspace]
members = ["foo_tests"]
default-members = ["foo"]

So that foo is compiled when using cargo build and foo_tests only when using -p foo_tests ?

The rest is the same

# foo/Cargo.toml
[package]
name = "foo"
version = "0.1.0"
edition = "2021"
rust-version = "1.75.0"

# foo_tests/Cargo.toml
[package]
name = "foo_tests"
version = "0.1.0"
edition = "2024"

[dependencies]
foo = { path = "../foo" }

Unless I did something wrong (maybe using default_members and members that way is wrong.)

[epage]

default-members will control which packages are operated on by default but we still need to generate a Cargo.lock for those operations and that requires the entire workspace.

[epage]

Related issues:

• unstable features breaks unrelated sub-project #6015
• artifact-dependencies cause entire workspace to be nightly-only #12385
• Exclude all non-members from workspace #13600
• Cannot compile crate with cargo <1.71 if any crate in workspace depends on a crate that uses dep: syntax #15360
• It is impossible to compile any individual Edition 2021 package in a workspace using Cargo 2021 if there is even one Edition 2024 package #15894