Repository navigation
ICE: "no entry found for key" while building stage0 tools #88488
Copy link
Copy link
Closed
Labels
A-incr-compArea: Incremental compilationArea: Incremental compilationC-bugCategory: This is a bug.Category: This is a bug.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-betaPerformance or correctness regression from stable to beta.Performance or correctness regression from stable to beta.
Milestone
Description
Checked out the latest version of the compiler today to write a patch, but ran into an ICE when doing py check. I haven't changed anything recently, so not sure what's causing this.
Code
Compiling the compiler at commit 13edc17
Meta
rustc --version --verbose:
rustc 1.55.0-beta.1 (739f8f0a8 2021-07-28) running on x86_64-pc-windows-gnu
Error output
thread 'rustc' panicked at 'no entry found for key', compiler\rustc_query_impl\src\on_disk_cache.rs:175:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md
note: rustc 1.55.0-beta.1 (739f8f0a8 2021-07-28) running on x86_64-pc-windows-gnu
note: compiler flags: -Z macro-backtrace -Z binary-dep-depinfo -Z force-unstable-if-unmarked -C opt-level=3 -C embed-bitcode=no -C debuginfo=0 -C incremental -C llvm-args=-import-instr-limit=10 --crate-type dylib
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
#0 [predicates_of] computing predicates of `common::FunctionCx`
#1 [check_item_well_formed] checking that `abi::comments::add_arg_comment` is well-formed
end of query stack
error: could not compile `rustc_codegen_cranelift`
Backtrace
PS C:\Users\yoshu\Code\rust> py .\x.py check
Updating only changed submodules
Submodules updated in 0.11 seconds
Finished dev [unoptimized + debuginfo] target(s) in 2.15s
Checking stage0 std artifacts (x86_64-pc-windows-gnu -> x86_64-pc-windows-gnu)
Finished release [optimized] target(s) in 0.59s
Checking stage0 std test/bench/example targets (x86_64-pc-windows-gnu
-> x86_64-pc-windows-gnu)
Finished release [optimized] target(s) in 0.59s
Checking stage0 compiler artifacts (x86_64-pc-windows-gnu -> x86_64-pc-windows-gnu)
warning: library kind `static-nobundle` has been superseded by specifying `-bundle` on library kind `static`. Try `static:-bundle`
warning: `rustc_llvm` (lib) generated 1 warning
warning: `rustc_llvm` (lib test) generated 1 warning (1 duplicate)
Finished release [optimized] target(s) in 1.97s
Checking stage0 rustdoc artifacts (x86_64-pc-windows-gnu -> x86_64-pc-windows-gnu)
Finished release [optimized] target(s) in 0.98s
Checking stage0 cranelift artifacts (x86_64-pc-windows-gnu -> x86_64-pc-windows-gnu)
Checking rustc_codegen_cranelift v0.1.0 (C:\Users\yoshu\Code\rust\compiler\rustc_codegen_cranelift)
thread 'rustc' panicked at 'no entry found for key', compiler\rustc_query_impl\src\on_disk_cache.rs:175:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md
note: rustc 1.55.0-beta.1 (739f8f0a8 2021-07-28) running on x86_64-pc-windows-gnu
note: compiler flags: -Z macro-backtrace -Z binary-dep-depinfo -Z force-unstable-if-unmarked -C opt-level=3 -C embed-bitcode=no -C debuginfo=0 -C incremental -C llvm-args=-import-instr-limit=10 --crate-type dylib
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
#0 [predicates_of] computing predicates of `common::FunctionCx`
#1 [check_item_well_formed] checking that `abi::comments::add_arg_comment` is well-formed
end of query stack
error: could not compile `rustc_codegen_cranelift`
Caused by:
process didn't exit successfully: `C:\Users\yoshu\Code\rust\build\bootstrap/debug/rustc --crate-name rustc_codegen_cranelift --edition=2018 src\lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type dylib --emit=dep-info,metadata -C opt-level=3 -C embed-bitcode=no -C debuginfo=0 -C metadata=46f7e1b0fd3f3e68 -C extra-filename=-46f7e1b0fd3f3e68 --out-dir C:\Users\yoshu\Code\rust\build\x86_64-pc-windows-gnu\stage0-codegen\x86_64-pc-windows-gnu\release\deps --target x86_64-pc-windows-gnu -C incremental=C:\Users\yoshu\Code\rust\build\x86_64-pc-windows-gnu\stage0-codegen\x86_64-pc-windows-gnu\release\incremental -L dependency=C:\Users\yoshu\Code\rust\build\x86_64-pc-windows-gnu\stage0-codegen\x86_64-pc-windows-gnu\release\deps -L dependency=C:\Users\yoshu\Code\rust\build\x86_64-pc-windows-gnu\stage0-codegen\release\deps --extern ar=C:\Users\yoshu\Code\rust\build\x86_64-pc-windows-gnu\stage0-codegen\x86_64-pc-windows-gnu\release\deps\libar-008c953fc1022421.rmeta --extern cranelift_codegen=C:\Users\yoshu\Code\rust\build\x86_64-pc-windows-gnu\stage0-codegen\x86_64-pc-windows-gnu\release\deps\libcranelift_codegen-e3f012bff9079dc3.rmeta --extern cranelift_frontend=C:\Users\yoshu\Code\rust\build\x86_64-pc-windows-gnu\stage0-codegen\x86_64-pc-windows-gnu\release\deps\libcranelift_frontend-70b32e62a9b56945.rmeta --extern cranelift_module=C:\Users\yoshu\Code\rust\build\x86_64-pc-windows-gnu\stage0-codegen\x86_64-pc-windows-gnu\release\deps\libcranelift_module-a02560616de272a2.rmeta --extern cranelift_native=C:\Users\yoshu\Code\rust\build\x86_64-pc-windows-gnu\stage0-codegen\x86_64-pc-windows-gnu\release\deps\libcranelift_native-69d1bf02ade6427b.rmeta --extern cranelift_object=C:\Users\yoshu\Code\rust\build\x86_64-pc-windows-gnu\stage0-codegen\x86_64-pc-windows-gnu\release\deps\libcranelift_object-8c36e952eceda322.rmeta --extern gimli=C:\Users\yoshu\Code\rust\build\x86_64-pc-windows-gnu\stage0-codegen\x86_64-pc-windows-gnu\release\deps\libgimli-8c830305f513e434.rmeta --extern indexmap=C:\Users\yoshu\Code\rust\build\x86_64-pc-windows-gnu\stage0-codegen\x86_64-pc-windows-gnu\release\deps\libindexmap-509c3c26a3c04416.rmeta --extern
object=C:\Users\yoshu\Code\rust\build\x86_64-pc-windows-gnu\stage0-codegen\x86_64-pc-windows-gnu\release\deps\libobject-b937931e2b43b5fb.rmeta --extern smallvec=C:\Users\yoshu\Code\rust\build\x86_64-pc-windows-gnu\stage0-codegen\x86_64-pc-windows-gnu\release\deps\libsmallvec-bf0557f61df3ef35.rmeta --extern target_lexicon=C:\Users\yoshu\Code\rust\build\x86_64-pc-windows-gnu\stage0-codegen\x86_64-pc-windows-gnu\release\deps\libtarget_lexicon-d1e221e5b1c4e96c.rmeta --cfg=bootstrap -Zmacro-backtrace -Cllvm-args=-import-instr-limit=10 -Z binary-dep-depinfo` (exit code: 0x80000003)
Build completed unsuccessfully in 0:00:20
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
A-incr-compArea: Incremental compilationArea: Incremental compilationC-bugCategory: This is a bug.Category: This is a bug.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-betaPerformance or correctness regression from stable to beta.Performance or correctness regression from stable to beta.
Activity
[-]Internal Compiler Error: "no entry found for key" in rustc_codegen_cranelift[/-][+]Internal Compiler Error: "no entry found for key" while bootstrapping rustc_codegen_cranelift[/+]Aaron1011 commentedon Aug 30, 2021
It looks like old incremental compilation data is getting reused. I believe that this should be fixed by #86641.
In the meantime, running
./x.py cleanshould fix this.jyn514 commentedon Mar 30, 2022
Duplicate of #76720.
jyn514 commentedon Mar 18, 2023
This is not actually a duplicate. This happens in stage0, not stage1, so it's not related to sharing the version string between different dev builds. It might be the case that we're not clearing the cache when we update the beta compiler, but that will have a different fix and should be tracked separately.
(It happened to me this morning)
backtrace
[-]Internal Compiler Error: "no entry found for key" while bootstrapping rustc_codegen_cranelift[/-][+]ICE: "no entry found for key" while bootstrapping tools[/+][-]ICE: "no entry found for key" while bootstrapping tools[/-][+]ICE: "no entry found for key" while building stage0 tools[/+]jyn514 commentedon Mar 18, 2023
The strange thing to me is that we shouldn't need to clear the stage0 cache - beta should just be ignoring incremental artifacts that don't match the version hash. @cjgillot @michaelwoerister do you know what could be going on here?
jyn514 commentedon Mar 18, 2023
I do think this is a purely incremental bug because
rm -r build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/release/incremental/fixed the issue, I didn't need to clear any .rmeta files.15 remaining items
Auto merge of #109935 - michaelwoerister:fix-feed-in-eval-always, r=c…
jyn514 commentedon Jun 5, 2023
someone on discord ran into a similar bug today:
jyn514 commentedon Jul 2, 2023
ran into the same thing myself
Details
jyn514 commentedon Jul 2, 2023
cc @Mark-Simulacrum this is likely a real regression that's going to end up in 1.71 - unclear which PR caused it so probably not much to do at this point but thought you'd want to know since the release is going out soon
Mark-Simulacrum commentedon Jul 2, 2023
Tagging for prioritization. It's not clear to me how impactful this is; I know I've seen and heard about other(?) incremental problems in 1.70 as well -- I think there's been some issues filed. Unfortunately I don't think we've found solutions that eliminate the problem at the root so just need to hope we don't introduce new ones :/
hameerabbasi commentedon Jul 2, 2023
I wrote a script based on this statement; intending to run a
git bisect --no-checkout, but it didn't reproduce for me on macOS x86_64.jyn514 commentedon Jul 2, 2023
yes, sorry - there are several issues mixed into the history here and not all of them are the same. the one that's going to land in 1.71 is #112700, which no one has been able to reliably reproduce. the one boxy ran into was likely fixed by #109935 and no longer reproduces on master.
make sure that you do not rebase over any version bump. if the stage0 compiler changes, your testing is invalid (because they just won't read the same metadata files).
hameerabbasi commentedon Jul 2, 2023
If all issues mixed in here are tracked elsewhere cleanly, perhaps it makes sense to close this one?
michaelwoerister commentedon Jul 3, 2023
Closing this as a duplicate of #108481 (which has been fixed by #109935).