Summary
Quite often when working on bootstrap, I run into this error (precisely this error):
thread 'main' (57) panicked at src/bootstrap/src/lib.rs:1316:16:
no entry found for key
This is quite unhelpful and gives no indication of what went wrong.
The proximate problem is that Build::cc is trying to load a compiler for a target that wasn't cached at startup:
|
/// Returns the path to the C compiler for the target specified. |
|
fn cc(&self, target: TargetSelection) -> PathBuf { |
|
if self.config.dry_run() { |
|
return PathBuf::new(); |
|
} |
|
self.cc[&target].path().into() |
This is not very satisfying though: why wasn't it cached? what target isn't cached? how did bootstrap even reach this path?
Because this happens dynamically, it's often very hard to reproduce this error without target-specific setup, which makes it even harder to debug.
Command used
./x.py --stage 2 test tests/incremental --ferrocene-test-one-crate-per-cargo-call --test-variant 2021-cortex-a53 --host=x86_64-unknown-linux-gnu --target=aarch64-unknown-ferrocene.facade
(I do not expect you to be able to reproduce it. This being hard to reproduce is kind of the point. It took us about two hours internally and that was with access to the CI logs.)
Expected behaviour
It would be nice to do one or both of two things:
- Unconditionally show a stack trace when this error happens (maybe we can do this for all indexing errors in bootstrap somehow?), and print the target which failed
- Change
cc loading to happen at runtime, rather than up-front, so it's no longer a hard error if bootstrap gets its caching wrong; i.e. we only have one source of truth and not two.
Actual behaviour
A bare panic with no indication of what went wrong.
Bootstrap configuration (bootstrap.toml)
oh god i really have no idea
Operating system
x86_64-ubuntu-20
HEAD
ferrocene/ferrocene@93cde04:
Additional context
This particular reproducer happened in Ferrocene, but I have seen this in a bunch of other places. One example upstream is #143561.
Enable backtrace and verbose mode if possible for more detailed information e.g., with RUST_BACKTRACE=1 ./x build -v.
don't i WISH
Summary
Quite often when working on bootstrap, I run into this error (precisely this error):
This is quite unhelpful and gives no indication of what went wrong.
The proximate problem is that
Build::ccis trying to load a compiler for a target that wasn't cached at startup:rust/src/bootstrap/src/lib.rs
Lines 1263 to 1268 in 561ea2b
This is not very satisfying though: why wasn't it cached? what target isn't cached? how did bootstrap even reach this path?
Because this happens dynamically, it's often very hard to reproduce this error without target-specific setup, which makes it even harder to debug.
Command used
./x.py --stage 2 test tests/incremental --ferrocene-test-one-crate-per-cargo-call --test-variant 2021-cortex-a53 --host=x86_64-unknown-linux-gnu --target=aarch64-unknown-ferrocene.facade(I do not expect you to be able to reproduce it. This being hard to reproduce is kind of the point. It took us about two hours internally and that was with access to the CI logs.)
Expected behaviour
It would be nice to do one or both of two things:
ccloading to happen at runtime, rather than up-front, so it's no longer a hard error if bootstrap gets its caching wrong; i.e. we only have one source of truth and not two.Actual behaviour
A bare panic with no indication of what went wrong.
Bootstrap configuration (bootstrap.toml)
oh god i really have no idea
Operating system
x86_64-ubuntu-20
HEAD
ferrocene/ferrocene@93cde04:
Additional context
This particular reproducer happened in Ferrocene, but I have seen this in a bunch of other places. One example upstream is #143561.
don't i WISH