Cargo panics when forced-target is specified to be i686-pc-windows-msvc

[amnestria]

Problem

When attempting to compile a crate that has i686-pc-windows-msvc forced as its target, Cargo panics:

thread 'main' panicked at src/cargo\core\resolver\features.rs:323:14:
activated_features for invalid package: features did not find PackageId { name: "windows_i686_msvc", version: "0.52.6", source: "registry `crates-io`" } NormalOrDev
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Steps

1. Enable the experimental Cargo feature per-package-target inside Cargo.toml.
2. Specify package.forced-target to be i686-pc-windows-msvc.
3. Compile.

Possible Solution(s)

No response

Notes

No response

Version

release: 1.83.0-nightly
commit-hash: ad074abe3a18ce8444c06f962ceecfd056acfc73
commit-date: 2024-10-04
host: x86_64-pc-windows-msvc
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.9.0-DEV (sys:0.4.74+curl-8.9.0 vendored ssl:Schannel)
os: Windows 10.0.19044 (Windows 10 IoT Enterprise LTSC 2021) [64-bit]

[weihanglo]

Thanks for the bug report. Mind sharing your Cargo.toml, or any minimal reproducible example?
A plain Cargo.toml with the steps you described in cargo 1.84.0-nightly (4a2d8dc63 2024-11-09) doesn't panic.

[amnestria]

It's seems that you're correct, @weihanglo. The windows crate causes Cargo to panic:

cargo-features = ["per-package-target"]

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

forced-target = "i686-pc-windows-msvc"

[dependencies.windows]
version  = "0.58.0"
features = ["Win32_System_LibraryLoader", "Win32_System_Threading", "Win32_System_Environment"]

[weihanglo]

I see. Thanks for the reproducible example. This can be minimized to this.

cargo-features = ["per-package-target"]

[package]
name = "foo"
edition = "2021"

forced-target = "wasm32-unknown-unknown"

[target.wasm32-unknown-unknown.dependencies]
empty-library = "1"

There are like a few different "bugs" here

• The panic happened because the v2 feature resolver didn't take forced-target into account, so the target specific dependency was never activated.
• Several places calling BuildConfig::requested_kinds don't consider anything from default-target or forced-target, so some target platform info may be missing.

The fix for the latter should be a bit easier. Managing all calls to requested_kinds through on a new requested_kinds method, which reuse a similar logic like this one. This should resolve the issue if only your top-level primary package has forced-target specified.

However, for the former, the situation become really really tricky.

Should the “forced-target” behavior be like what artifact-dependencies feature has provided via the target field on a dependency? Specifically, if a dependency bar is forced to build to wasm32-unknown-unknown, should the entire dependency subtree from bar also compile to wasm? -Zbindeps does that btw so a fix will be quite similar, however upon the already-complicated and error-prone logic.

I wasn't involved but feel like the per-package-target feature was loosely discussed, the expected behavior remains unclear. And as pointed out in the tracking issue, its use cases are somehow overlapped and also incompatible with artifact dependencies. I think instead of a temporary fix, we can discuss the direction of these two features.

[weihanglo]

Note that with resolver = "1" in the primary package or workspace, the panic is gone.