`cargo new` sometimes generates invalid Cargo.toml when new crate is in a subdirectory of a workspace with Cargo 1.71

[Be-ing]

Problem

A crate in a subdirectory of a workspace opting out of being in the workspace via an empty [workspace] table or specifying its path in workspace.exclude in the workspace root's Cargo.toml fails on Windows with Cargo 1.71 whereas it worked with previous versions of Cargo.

Steps

Create a crate in a subdirectory of a workspace with the following Cargo.toml:

[package]
name = "required_libs"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
[lib]
crate-type=["staticlib"]
[workspace]

Running cargo commands fail:

 'C:/Program Files/Microsoft Visual Studio/2022/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/bin/cmake.exe' '-E' 'env' 'CARGO_BUILD_RUSTC=C:/Users/runneradmin/.rustup/toolchains/stable-x86_64-pc-windows-msvc/bin/rustc.exe' 'C:/Users/runneradmin/.rustup/toolchains/stable-x86_64-pc-windows-msvc/bin/cargo.exe' 'rustc' '--verbose' '--color' 'never' '--target=x86_64-pc-windows-msvc' '--' '--print=native-static-libs'
error: failed to parse manifest at `C:\cxx-qt\build\corrosion\required_libs\Cargo.toml`
Caused by:
  error inheriting `version` from workspace root manifest's `workspace.package.version`
Caused by:
  `workspace.package.version` was not defined

Removing the empty [workspace] table from Cargo.toml fails with a different error. This error is also shown when specifying workspace.exclude = [ "path/to/subdir" ] in the workspace root's Cargo.toml:

'C:/Program Files/Microsoft Visual Studio/2022/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/bin/cmake.exe' '-E' 'env' 'CARGO_BUILD_RUSTC=C:/Users/runneradmin/.rustup/toolchains/stable-x86_64-pc-windows-msvc/bin/rustc.exe' 'C:/Users/runneradmin/.rustup/toolchains/stable-x86_64-pc-windows-msvc/bin/cargo.exe' 'rustc' '--verbose' '--color' 'never' '--target=x86_64-pc-windows-msvc' '--' '--print=native-static-libs'
error: current package believes it's in a workspace when it's not:
current:   C:\cxx-qt\build\corrosion\required_libs\Cargo.toml
workspace: C:\cxx-qt\Cargo.toml
this may be fixable by adding `build\corrosion\required_libs` to the `workspace.members` array of the manifest located at: C:\cxx-qt\Cargo.toml
Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.

Possible Solution(s)

I encounter this when using Corrosion to invoke Cargo via CMake as part of building a C++ application. At CMake configure time, Corrosion autogenerates a dummy staticlib crate with the above Cargo.toml to run cargo rustc -- --print=native-static-libs, which is used to tell CMake what system libraries need to be linked whenever linking a staticlib into a C/C++ build. The generated dummy crate is put in the CMake build directory, which conventionally is inside the code repository, which also contains the workspace's virtual Cargo.toml manifest.

A workaround for this particular scenario is to create the CMake build directory outside of the code repository.

If rustc had some way to get the list of native-static-libs needed for every staticlib crate without needing to generate a dummy crate, this situation could be avoided.

Notes

Downstream Corrosion bug: corrosion-rs/corrosion#418

Somehow this bug is only occurring on Windows. Linux and macOS builds still work fine with Rust 1.71.

The root Cargo.toml for the workspace is:

[workspace]
members = [
    "crates/cxx-qt",
    "crates/cxx-qt-build",
    "crates/cxx-qt-gen",
    "crates/cxx-qt-lib",
    "crates/cxx-qt-lib-headers",
    "crates/qt-build-utils",

    "examples/cargo_without_cmake",
    "examples/demo_threading/rust",
    "examples/qml_extension_plugin/plugin/rust",
    "examples/qml_features/rust",
    "examples/qml_minimal/rust",

    "tests/basic_cxx_only/rust",
    "tests/basic_cxx_qt/rust",
    "tests/qt_types_standalone/rust",
]

[workspace.package]
edition = "2021"
license = "MIT OR Apache-2.0"
repository = "https://github.com/KDAB/cxx-qt/"
version = "0.5.3"

# Note a version needs to be specified on dependencies of packages
# we publish, otherwise crates.io complains as it doesn't know the version.
[workspace.dependencies]
cxx-qt = { path = "crates/cxx-qt" }
cxx-qt-macro = { path = "crates/cxx-qt-macro" }
cxx-qt-build = { path = "crates/cxx-qt-build" }
cxx-qt-gen = { path = "crates/cxx-qt-gen", version = "0.5.3" }
cxx-qt-lib = { path = "crates/cxx-qt-lib" }
cxx-qt-lib-headers = { path = "crates/cxx-qt-lib-headers", version = "0.5.3" }
qt-build-utils = { path = "crates/qt-build-utils", version = "0.5.3" }

# Ensure that the example comments are kept in sync
# examples/cargo_without_cmake/Cargo.toml
# examples/qml_minimal/rust/Cargo.toml
cxx = "1.0.95"
cxx-build = { version = "1.0.95", features = [ "parallel" ] }
cxx-gen = "0.7.95"
convert_case = "0.6"
proc-macro2 = "1.0"
syn = { version = "2.0", features = ["extra-traits", "full"] }
quote = "1.0"
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"

Version

1.71

[epage]

Skimming through the 1.71 commits, nothing really stands out that would touch these areas. "workspace" appears a lot because this was when we switched to a workspace. We also touched workspace-related code but in the periphery, like cargo new.

[epage]

The error for the reproduction steps in the issue is also strange. It is trying to load workspace.package.version but the manifest listed doesn't reference it.

[Be-ing]

Perhaps the error is misleading? Maybe a problem occurred in a tangentially related part of the Cargo codebase that doesn't get caught immediately?

[Be-ing]

Skimming through the 1.71 commits, nothing really stands out that would touch these areas.

d6455a2 (#12317) touches code leading to the error, but it doesn't seem like that change would be the problem. Nevermind I was looking at the master branch.

[jschwe]

We are using cargo new --lib required_libs to let cargo generate a library crate for us. It appears that if there is a workspace in a parent directory, cargo will now (sometimes?) write version.workspace = true instead of version = "0.1.0" into the Cargo.toml.

I find this behavior a bit strange, since cargo also outputs the warning current package believes it's in a workspace when it's not:.

[Be-ing]

Well this is interesting. On GitHub Actions, cargo new --lib required_libs is generating a different Cargo.toml. The Cargo.toml I included in the first post was made from cargo new --lib required_libs locally on Linux assuming that it would be the same on CI. Here is what gets generated on CI:

[package]
name = "required_libs"
edition.workspace = true
license.workspace = true
repository.workspace = true
version.workspace = true

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

then Corrosion adds an empty [workspace] table, which explains the error. version.workspace = true is used on Linux, macOS, and Windows, but somehow, Cargo only fails on Windows???

Manually editing the locally generated Cargo.toml to version.workspace = true on Linux reproduces the error:

required_libs on  main [?] via 🦀 v1.72.0-dev 
❯ cargo build
error: failed to parse manifest at `/home/be/sw/cxx-qt/build/corrosion/required_libs/Cargo.toml`

Caused by:
  error inheriting `version` from workspace root manifest's `workspace.package.version`

Caused by:
  `workspace.package.version` was not defined

[weihanglo]

Pretty strange. I couldn't quite follow the reproducible steps. Is there a minimal reproduction without cmake involvement? Or could you provide a repository that people can clone and build and see the error?

BTW, the directory you ran a command is also a important part of reproduction. It would be great if we can have this piece of information.

I also wonder if there is any member crate depending on the generated crate? That could turn generated crate into a workspace member automatically.

[epage]

In 1.71, we added this feature. The inconsistent behavior could be a difference in CI between platforms or we could have a bug in detecting if there is a workspace present. As was said, independent reproduction steps will be important.

While we should root cause and fix this issue, I wonder if "cargo new" is intended for automation, if we intend the level of compatibility needed for automation or only or user interaction.