Target-gated dependencies not included in a workspace are "discovered" anyways

[Radbuglet]

Problem and Steps

As a minimum reproducible project, I have a workspace...

[workspace]
resolver = "2"
members = ["crates/entry"]

...and two crates crates/entry and crates/dep.

crates/dep/src/lib.rs contains the code:

compile_error!("`dep` included");

...in other words, I do not expect dep to be compiled.

Meanwhile, crates/entry/Cargo.toml contains...

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

[target.'cfg(any())'.dependencies]
dep = { path = "../dep" }

Since the cfg is disabled, I'd expect dep not to be compiled but it seems to get compiled anyways...

% cargo check
    Checking dep v0.1.0 (crates/dep)
error: `dep` included
 --> crates/dep/src/lib.rs:1:1
  |
1 | compile_error!("`dep` included");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: could not compile `dep` (lib) due to 1 previous error

If I comment out the [target.'cfg(any())'.dependencies] table entirely, the code does compile so dep is only being discovered as part of the dependency list for a target which is inactive.

The current workaround seems to be to mention dep explicitly in the workspace.exclude section of the workspace's Cargo.toml:

[workspace]
resolver = "2"
members = ["crates/entry"]
exclude = ["crates/dep"]

Is this a bug? It was certainly a little bit surprising to me.

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.83.0 (5ffbef321 2024-10-29)
release: 1.83.0
commit-hash: 5ffbef3211a8c378857905775a15c5b32a174d3b
commit-date: 2024-10-29
host: aarch64-apple-darwin
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.7.1 (sys:0.4.74+curl-8.9.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Mac OS 15.1.0 [64-bit]

[epage]

From the members documentation

All path dependencies residing in the workspace directory automatically become members. Additional members can be listed with the members key, which should be an array of strings containing directories with Cargo.toml files.

Similarly, when you run cargo check in the root of a workspace with a virtual manifest, it selects all workspace members, see the package selection documentation

If this is not what you want, you can workaround this with exclude

The exclude key can be used to prevent paths from being included in a workspace. This can be useful if some path dependencies aren’t desired to be in the workspace at all, or using a glob pattern and you want to remove a directory.

There is interest in declaring in a package a supported set of platforms which would have them filtered out, see #6179

[Radbuglet]

Seems this is intended behavior, then.