Panic when depending on a package with artifact dependencies

[ferologics]

Problem

We hit a thread 'main' panicked at 'no entry found for key' error in our project. We're testing the use of various build artifacts (wasm/staticlib) in our setup. We have a project-wide config.toml with bindeps = true.

error from cargo check

thread 'main' panicked at 'no entry found for key', src/tools/cargo/src/cargo/core/compiler/build_context/target_info.rs:901:40
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic_display
   3: core::panicking::panic_str
   4: core::option::expect_failed
   5: <cargo::core::compiler::build_context::target_info::RustcTargetData>::info
   6: <core::iter::adapters::map::Map<std::collections::hash::set::Iter<cargo::core::compiler::compile_kind::CompileKind>, <cargo::core::compiler::compilation::Compilation>::new::{closure#0}> as core::iter::traits::iterator::Iterator>::fold::<(), core::iter::traits::iterator::Iterator::for_each::call<(cargo::core::compiler::compile_kind::CompileKind, std::path::PathBuf), <hashbrown::map::HashMap<cargo::core::compiler::compile_kind::CompileKind, std::path::PathBuf, std::collections::hash::map::RandomState> as core::iter::traits::collect::Extend<(cargo::core::compiler::compile_kind::CompileKind, std::path::PathBuf)>>::extend<core::iter::adapters::map::Map<std::collections::hash::set::Iter<cargo::core::compiler::compile_kind::CompileKind>, <cargo::core::compiler::compilation::Compilation>::new::{closure#0}>>::{closure#0}>::{closure#0}>
   7: <std::collections::hash::map::HashMap<cargo::core::compiler::compile_kind::CompileKind, std::path::PathBuf> as core::iter::traits::collect::FromIterator<(cargo::core::compiler::compile_kind::CompileKind, std::path::PathBuf)>>::from_iter::<core::iter::adapters::map::Map<std::collections::hash::set::Iter<cargo::core::compiler::compile_kind::CompileKind>, <cargo::core::compiler::compilation::Compilation>::new::{closure#0}>>
   8: <cargo::core::compiler::compilation::Compilation>::new
   9: <cargo::core::compiler::context::Context>::new
  10: cargo::ops::cargo_compile::compile_ws
  11: cargo::ops::cargo_compile::compile
  12: cargo::commands::check::exec
  13: cargo::cli::main
  14: cargo::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Notes

possibly related to #10444

Version

cargo 1.66.0-nightly (b332991a5 2022-10-13)
release: 1.66.0-nightly
commit-hash: b332991a57c9d055f1864de1eed93e2178d49440
commit-date: 2022-10-13
host: aarch64-apple-darwin
libgit2: 1.5.0 (sys:0.15.0 vendored)
libcurl: 7.79.1 (sys:0.4.55+curl-7.83.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 12.6.0 [64-bit]

[tsoutsman]

AFAICT the panic occurs when a package has a transitive artifact dependency whose target isn't in the list of targets that the package directly interacts with.

More specifically, the artifact_targets function in src/cargo/core/compiler/build_context/target_info.rs does not consider the targets of transitive artifact dependencies. I don't know how easy of a fix it is.

Example

foo/Cargo.toml:

[dependencies.bar]
path = "../bar"

bar/Cargo.toml:

[dependencies.baz]
artifact = "bin"
path = "../baz"
target = "x86_64-unknown-uefi"

foo will only successfully compile for the x86_64-unknown-uefi target. Otherwise, it will spit out the aforementioned panic.

[weihanglo]

It's a bit tricky to provide a detailed message, narrowing down to which crate requires the specific target. If that's feasible, Cargo should give such a message:

error: could not find specification for target "x86_64-windows-msvc"
    Dependency `bar v0.1.0` requires to build for target "x86_64-windows-msvc".

However, this is the line called by target_info.rs, which indexes RustTargetData.target_info and panics. target_info is prepared upfront before the dependency graph being resolved. That is to say, it is highly possible that target_info doesn't contain a given target triple information from an artifact dependency requesting for.

To achieve that, we could teach the dependency resolver to check target platform availability. Yet it sounds like a bad idea to me since there are already too many works inside the resolver.

Instead, the second approach is relatively easy, by giving a message telling people which target platform info is missing, as well as how to check and how to fix it. Take this failure for instance,

cargo b --target x86_64-windows-msvc
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names --target x86_64-windows-msvc --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg` (exit status: 1)
  --- stderr
  error: Error loading target specification: Could not find specification for target "x86_64-windows-msvc". Run `rustc --print target-list` for a list of built-in targets

Could copy fn info() to create a new try_info function, returning a Result<TargetInfo>, and bailing out with an informative message like above when a target info cannot be found.

I am able to guide through the second easy approach. If anyone wants to try the first one, it is probably beyond my knowledge. Suit up and good luck!

[jofas]

Hi @weihanglo with some guidance I'd like to implement the second approach.

@rustbot claim

[weihanglo]

Edited: the error message doesn't real resolve the issue. We need to figure out a way to really solve the problem.

Sure. Here are the instructions:

• RustcTargetData::info(…) panics when a target cannot be found. We could first create a fallible variant RustcTargetData::try_info(…) returning a Result.
• Here, we call try_info and propagate the error. The error should be
  • Actionable: Tell the user how to proceed and fix. The error message from rustc "Run rustc --print target-list for a list of built-in targets" is a good candidate to learn from.
  • Succinct: Be concise and still have the right amount of information. Should mention the possible root cause. So, we could probably walk through bcx.unit_graph and check which unit matches that CompileKind.
• Continue. The message could be like this:

  error: could not find specification for target "x86_64-windows-msvc"
    Dependency `bar v0.1.0` requires to build for target "x86_64-windows-msvc".
  

  where bar v0.1.0 can be found via the Display impl for unit.pkg.

This is just one of the solution. You can probably find a better one than mine.