Configuration specific dependencies break cargo tree

[abrisco]

Problem

Running cargo tree on the following yaml now fails in Nightly releases of Cargo

[package]
name = "target_cfg_features"
version = "0.1.0"
edition = "2018"

# Required to satisfy cargo but no `lib.rs` is expected to
# exist within test data.
[lib]
path = "lib.rs"

[dependencies]
tokio = "1.25.0"

[target.'cfg(unix)'.dependencies.tokio]
features = ["fs"]

Stable

target_cfg_features v0.1.0 (/target_cfg_features)
└── tokio v1.25.0
    └── pin-project-lite v0.2.9
    [build-dependencies]
    └── autocfg v1.1.0

Nightly

error: failed to parse manifest at `/target_cfg_features/Cargo.toml`

Caused by:
  dependency (tokio) specified without providing a local path, Git repository, version, or workspace dependency to use

Steps

Use Cargo.toml from above and run cargo tree

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.78.0 (54d8815d0 2024-03-26)
cargo 1.80.0-nightly (6087566b3 2024-04-30)

[weihanglo]

It was a bug we fixed recently in #13775. The bug has been there for a long while. Now Cargo disallows dependencies without any source, to avoid confusion.

dependency (tokio) specified without providing a local path, Git repository, version, or workspace dependency to use

To fix this, follow the instruction and specify a version, or any other kind of dependency. Like

[target.'cfg(unix)'.dependencies.tokio]
features = ["fs"]
version = "1.25.0"

[abrisco]

Is there a way to refer to the same version defined in [dependencies] directly?

[abrisco]

And what was the behavior before? It certainly seems like the behavior was to inherit the version from [dependencies]. It seems like the intent of #13775 was to fix

[dependencies]
tokio = {}

not prohibit the example in the original post. I think I lack some context to comprehend everything in the original post though.

[weihanglo]

Is there a way to refer to the same version defined in [dependencies] directly?

If you have a Cargo workspace, [workspace.dependencies] is made for that.

It certainly seems like the behavior was to inherit the version from [dependencies]

No it was not. If you remove the entire [dependencies] table from you example, and build with older Cargo, you will get the latest tokio as well. It was a bug that wrongly set version = "*" for every dependency that has no source kind. To prove it, run this command in you example project and check if the version req of tokio is *.

cargo metadata | jq '.packages[] | select(.name=="target_cfg_features")'

[abrisco]

Is there a way to refer to the same version defined in [dependencies] directly?

If you have a Cargo workspace, [workspace.dependencies] is made for that.

It certainly seems like the behavior was to inherit the version from [dependencies]

No it was not. If you remove the entire [dependencies] table from you example, and build with older Cargo, you will get the latest tokio as well. It was a bug that wrongly set version = "*" for every dependency that has no source kind. To prove it, run this command in you example project and check if the version req of tokio is *.

cargo metadata | jq '.packages[] | select(.name=="target_cfg_features")'

Does the current stable behavior (intended of otherwise) conform the target.cfg dependency to the version defined in [dependencies]? I definitely agree the case where [dependencies] is omitted and there's no version info in the target.cfg entry should fail. But certainly feels like this "fix" (which again I partially agree and am thankful for, thank you!) has taken away desired behavior.

My expectations are

1. All [dependencies] entries must have version info
2. Any unversioned target.cfg entries will inherit versions from [dependencies]
3. target.cfg entries are free to specify independent version info
4. target.cfg entries that do not match anything in [dependencies] should error if no version info is provided.

That being said, I lack the bandwidth to drive any of these changes so mostly wanted to share feedback and have some questions answered. I'll close this out for now until there's more engagement from other users.

Thank you for your time!

[weihanglo]

Does the current stable behavior (intended of otherwise) conform the target.cfg dependency to the version defined in [dependencies]

No. It was just a coincidence. The dependency resolver saw both syn = "1" from dependencies, and syn = "*" from target-specific dependencies. From the definition of * version requirement, it matches anything on that position.

I would say it was a bug (or misfeature if you like) that may lead to more dependency-confusions (in the sense of people being confused, not exactly dependency confusion attack), so I lean toward not supporting implicit dependency inheritance.