Tracking Issue for per-package-target

[Ekleog]

Summary

Feature gate: per_package_target Discussion: https://internals.rust-lang.org/t/proposal-move-some-cargo-config-settings-to-cargo-toml/13336 Implementation: https://github.com/rust-lang/cargo/pull/9030 Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#per-package-target Issues: https://github.com/rust-lang/cargo/labels/Z-per-package-target

Unresolved issues

• [ ] The interaction with proposals like RFC 3028 does not work well. Selection for targets to build happens at the workspace level instead of at a level where the full compile graph is known. This affects selected packages (target-specific dependencies) and feature resolution as well. There's also some possible confusion, as the per-package-target settings are ignored in dependencies.
• [ ] The exact interaction with feature resolution is a bit up in the air. This may not be super well-tested where in theory each target artifact should get an independently resolved feature graph (ish). Related to: https://github.com/rust-lang/cargo/issues/9521
• [ ] Interaction with -Zbuild-std

[MarkSwanson]

https://github.com/rust-lang/cargo/issues/9521 I'm not sure if I should place this here. Just trying to help with keeping track...

[FrankvdStam]

See https://github.com/rust-lang/cargo/issues/9537

[Airtz]

Another issue is the interaction with -Zmultitarget #8176

IMO we should be able to do the following:

[package]
forced-target = ["x86_64-pc-windows-msvc", "i686-pc-windows-msvc"]

[kennystrawnmusic]

Performing some exhaustive tests when attempting to resolve #9451 revealed that #9521 is likely a duplicate of it, all thanks to a very specific panic message that shows when an attempt to compile a per-package-target crate with -Zbuild-std is made using a local fork of Cargo with the check that returns the error mentioned in #9451 commented out.

[kaimast]

I tried to set forced target to wasm32-unknown-unknown for a project and get the following panic:

thread 'main' panicked at 'activated_features for invalid package: features did not find PackageId { name: "wasm-bindgen-futures", version: "0.4.28", source: "registry `crates-io`" } false

Stack backtrace:
   0: <cargo::core::resolver::features::ResolvedFeatures>::activated_features_int
   1: cargo::core::compiler::unit_dependencies::new_unit_dep_with_profile
   2: cargo::core::compiler::unit_dependencies::compute_deps
   3: cargo::core::compiler::unit_dependencies::deps_of
   4: cargo::core::compiler::unit_dependencies::deps_of
   5: cargo::core::compiler::unit_dependencies::deps_of
   6: cargo::core::compiler::unit_dependencies::deps_of_roots
   7: cargo::core::compiler::unit_dependencies::build_unit_dependencies
   8: cargo::ops::cargo_compile::create_bcx
   9: cargo::ops::cargo_compile::compile_ws
  10: cargo::ops::cargo_compile::compile
  11: cargo::commands::build::exec
  12: cargo::cli::execute_subcommand
  13: cargo::cli::main
  14: cargo::main
  15: std::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>
  16: std::rt::lang_start::<()>::{closure#0}
  17: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/48a5999fceeea84a8971634355287faa349909d4/library/core/src/ops/function.rs:259:13
  18: std::panicking::try::do_call
             at /rustc/48a5999fceeea84a8971634355287faa349909d4/library/std/src/panicking.rs:406:40
  19: std::panicking::try
             at /rustc/48a5999fceeea84a8971634355287faa349909d4/library/std/src/panicking.rs:370:19
  20: std::panic::catch_unwind
             at /rustc/48a5999fceeea84a8971634355287faa349909d4/library/std/src/panic.rs:133:14
  21: std::rt::lang_start_internal::{{closure}}
             at /rustc/48a5999fceeea84a8971634355287faa349909d4/library/std/src/rt.rs:128:48
  22: std::panicking::try::do_call
             at /rustc/48a5999fceeea84a8971634355287faa349909d4/library/std/src/panicking.rs:406:40
  23: std::panicking::try
             at /rustc/48a5999fceeea84a8971634355287faa349909d4/library/std/src/panicking.rs:370:19
  24: std::panic::catch_unwind
             at /rustc/48a5999fceeea84a8971634355287faa349909d4/library/std/src/panic.rs:133:14
  25: std::rt::lang_start_internal
             at /rustc/48a5999fceeea84a8971634355287faa349909d4/library/std/src/rt.rs:128:20
  26: main
  27: __libc_start_main
  28: <unknown>', src/tools/cargo/src/cargo/core/resolver/features.rs:296:14

Any idea what could be causing this?

The project compiles fine with wasm-pack. Not sure if that tool sets any special flags, but either way cargo should not panic.

[Ekleog]

Hmm this looks bad indeed. Do you have an example workspace to reproduce? (Replacing all the code with empty files should most likely still allow reproducing, I'd guess only keeping the Cargo.toml files should be enough)

[kaimast]

I made a test repository here.

You should get something like this when compiling simba-wasm without any flags:

~/dev/wasm-compile-test main ❯ cargo build --package=simba-wasm                                                         ⬢
thread 'main' panicked at 'activated_features for invalid package: features did not find PackageId { name: "wasm-bindgen-futures", version: "0.4.28", source: "registry `crates-io`" } false', src/tools/cargo/src/cargo/core/resolver/features.rs:296:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Interesting cargo build --target=wasm32-unknown-unknown --package=simba-wasm works fine.

[ghost]

Also related: #10518.

[nerosnm]

I'm having the same activated_features for invalid package panic

[nerosnm]

It looks like it might be related to a [target.'cfg(target_arch = "wasm32")'.dependencies] section in a path dependency's Cargo.toml.

[Qubasa]

cargo-features = ["per-package-target", "profile-rustflags"] don't work together. By this I mean the target does not get applied when profile-rustflags get used.

cargo-features = ["per-package-target", "profile-rustflags"]

[package]
name = "perf_kernel"
version = "0.1.0"
authors = ["Luis Hebendanz <[email protected]>"]
edition = "2021"
forced-target = "x86_64-unknown-none"

[profile.dev]
rustflags = [ "-C", "link-args=--image-base=0x200000" ]

Will fail with gcc: error: unrecognized command-line option '--image-base=0x200000' even though target defines ld.lld as linker

[max-cura]

Also ran into this:

thread 'main' panicked at 'activated_features for invalid package: features did not find PackageId { name: "js-sys", version: "0.3.60", source: "registry `crates-io`" } NormalOrDev

when running cargo check.

Had forced-target=wasm32-unknown-unknown in one of my crates (if I remove that line, it stops panicking), and the issue was coming from getrandom = { version="0.2.8", features=["js"] }, which has the following, which seems to be what's being referenced in the panic message:

[target.'cfg(all(any(target_arch = "wasm32", target_arch = "wasm64"), target_os = "unknown"))'.dependencies]
wasm-bindgen = { version = "0.2.62", default-features = false, optional = true }
js-sys = { version = "0.3", optional = true }

Stack backtrace:
   0: std::backtrace::Backtrace::create
   1: <:error>::msg::<:string::string>
   2: <:core::resolver::features::resolvedfeatures>::activated_features_int
   3: cargo::core::compiler::unit_dependencies::new_unit_dep_with_profile
   4: cargo::core::compiler::unit_dependencies::compute_deps
   5: cargo::core::compiler::unit_dependencies::deps_of
   6: cargo::core::compiler::unit_dependencies::deps_of
   7: cargo::core::compiler::unit_dependencies::deps_of
   8: cargo::core::compiler::unit_dependencies::deps_of
   9: cargo::core::compiler::unit_dependencies::deps_of_roots
  10: cargo::core::compiler::unit_dependencies::build_unit_dependencies
  11: cargo::ops::cargo_compile::create_bcx
  12: cargo::ops::cargo_compile::compile_ws
  13: cargo::ops::cargo_compile::compile
  14: cargo::commands::check::exec
  15: cargo::cli::main
  16: cargo::main
  17: std::sys_common::backtrace::__rust_begin_short_backtrace::
  18: std::rt::lang_start::::{closure#0}
  19: std::rt::lang_start_internal
  20: _main', src/tools/cargo/src/cargo/core/resolver/features.rs:321:14
stack backtrace:
   0:        0x1012b2328 - <:sys_common::backtrace::_print::displaybacktrace as core::fmt::display>::fmt::hcc0d0be5d915b423
   1:        0x1012d31c4 - core::fmt::write::hd192c56b84d0d5fc
   2:        0x1012ad4c4 - std::io::Write::write_fmt::hc875b6ab61d117f8
   3:        0x1012b213c - std::sys_common::backtrace::print::hfdc3c075d7f207b2
   4:        0x1012b3ddc - std::panicking::default_hook::{{closure}}::h9a29056d92273910
   5:        0x1012b3b34 - std::panicking::default_hook::h918749fa9e3bbd56
   6:        0x1012b42ec - std::panicking::rust_panic_with_hook::h115b7bf8f2adb68e
   7:        0x1012b4220 - std::panicking::begin_panic_handler::{{closure}}::h610771468070e0bf
   8:        0x1012b2748 - std::sys_common::backtrace::__rust_end_short_backtrace::h84374e7a8d4c9564
   9:        0x1012b3f7c - _rust_begin_unwind
  10:        0x10133cfe4 - core::panicking::panic_fmt::heb926c9af39e8a59
  11:        0x10133d31c - core::result::unwrap_failed::h0edb6ed598db9dd6
  12:        0x100c67424 - cargo[b7a945c812b2d771]::core::compiler::unit_dependencies::new_unit_dep_with_profile
  13:        0x100c64f00 - cargo[b7a945c812b2d771]::core::compiler::unit_dependencies::compute_deps
  14:        0x100c63b08 - cargo[b7a945c812b2d771]::core::compiler::unit_dependencies::deps_of
  15:        0x100c63cb4 - cargo[b7a945c812b2d771]::core::compiler::unit_dependencies::deps_of
  16:        0x100c63cb4 - cargo[b7a945c812b2d771]::core::compiler::unit_dependencies::deps_of
  17:        0x100c63cb4 - cargo[b7a945c812b2d771]::core::compiler::unit_dependencies::deps_of
  18:        0x100c63970 - cargo[b7a945c812b2d771]::core::compiler::unit_dependencies::deps_of_roots
  19:        0x100c62a70 - cargo[b7a945c812b2d771]::core::compiler::unit_dependencies::build_unit_dependencies
  20:        0x100f60fe0 - cargo[b7a945c812b2d771]::ops::cargo_compile::create_bcx
  21:        0x100f5f4d4 - cargo[b7a945c812b2d771]::ops::cargo_compile::compile_ws
  22:        0x100f5f3bc - cargo[b7a945c812b2d771]::ops::cargo_compile::compile
  23:        0x100b0c22c - cargo[4ef0020e058ba257]::commands::check::exec
  24:        0x100adbc60 - cargo[4ef0020e058ba257]::cli::main
  25:        0x100b1474c - cargo[4ef0020e058ba257]::main
  26:        0x100ab90b0 - std[d7a38f31206b4b19]::sys_common::backtrace::__rust_begin_short_backtrace::
  27:        0x100aa6bf4 - std[d7a38f31206b4b19]::rt::lang_start::::{closure#0}
  28:        0x1012a6824 - std::rt::lang_start_internal::hfc06c7bfe3f9fee2
  29:        0x100b16a9c - _main

[str4d]

How is this feature intended to interact with target.<target>.runner? My expectation was that if cargo run or cargo test is called on a package that has forced-target = "SOME_TARGET", then if a runner is configured via target.SOME_TARGET.runner it will be used. Instead it appears that the binary is compiled for the forced-target but run using the runner for the host target.

My motivation here is similar to #8112: I want to execute cargo test from inside folder foo/, where a foo/.cargo/config.toml currently sets build.target = "thumbv7em-none-eabihf", and have the test binary be run on an embedded device. Currently I do this by setting target.thumbv7em-none-eabihf.runner to a Bash script that changes directory to ../bar before calling cargo run ... (which compiles a tool on the host and then runs it to deploy the binary to the embedded device). However this isn't cross-platform, and there's no way to configure a different runner based on the host OS (that I can find), so I want to use cargo run --manifest-path ../bar/Cargo.toml ... directly as the runner.

[simbleau]

Please let's get some attention on this!