You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ICE: found unstable fingerprints on test ui\associated-type-bounds\traits-assoc-type-macros.rs #83311
Test ui\associated-type-bounds\traits-assoc-type-macros.rs.
<code>
I expected to see this happen: test passes.
Instead, this happened:
stdout:
------------------------------------------
------------------------------------------
stderr:
------------------------------------------
thread 'rustc' panicked at 'found unstable fingerprints for proc_macro_decls_static(traits_assoc_type_macros[317d])', C:\msys64\home\we\rust\compiler\rustc_query_system\src\query\plumbing.rs:593:5
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.52.0-dev running on x86_64-pc-windows-gnu
note: compiler flags: -Z threads=1 -Z ui-testing -Z deduplicate-diagnostics=no -Z emit-future-incompat-report -Z unstable-options -C prefer-dynamic -C rpath -C debuginfo=0 -C link-args=-fuse-ld=lld -C incremental
query stack during panic:
#0 [proc_macro_decls_static] looking up the derive registrar for a crate
#1 [analysis] running analysis passes on this crate
end of query stack
thread 'rustc' panicked at 'found unstable fingerprints for opt_def_kind(traits_assoc_type_macros[317d]::main)', C:\msys64\home\we\rust\compiler\rustc_query_system\src\query\plumbing.rs:593:5
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.52.0-dev running on x86_64-pc-windows-gnu
note: compiler flags: -Z threads=1 -Z ui-testing -Z deduplicate-diagnostics=no -Z emit-future-incompat-report -Z unstable-options -C prefer-dynamic -C rpath -C debuginfo=0 -C link-args=-fuse-ld=lld -C incremental
query stack during panic:
#0 [opt_def_kind] looking up definition kind of `main`
#1 [codegen_fn_attrs] computing codegen attributes of `main`
end of query stack
------------------------------------------
Another one from src/test/ui/async-await/issues/issue-64964.rs (also disappears after removing the incremental directories):
thread '<unnamed>' panicked at 'Error reading cached dep-graph: "invalid enum variant tag while decoding `DepKind`, expected 0..249"', compiler/rustc_incremental/src/persist/load.rs:186:22
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.53.0-dev running on x86_64-pc-windows-gnu
note: compiler flags: -Z threads=1 -Z ui-testing -Z deduplicate-diagnostics=no -Z emit-future-incompat-report -Z unstable-options -Z query-dep-graph -C prefer-dynamic -C rpath -C debuginfo=0 -C link-args=-fuse-ld=lld -C incremental
query stack during panic:
end of query stack
warning: could not decode incremental cache: Any
warning: 1 warning emitted
The second issue seems like an issue with the incremental cache not getting invalidated when the compiler version is changed. Normally, that happens because the nightly compiler date changes, but I think it might not be happening with a locally built compiler (since the version suffix is always -dev). I don't think it has anything to do with the original issue.
A note: This bug has evolved quite a bit from its original filing.
Many of the reported issues are not specifically about fingerprints.
A common theme among them is that they are all problems that arise on the x.py test ui test suite.
A recent discussion with @Mark-Simulacrum leads us to think that this may be very specific to local rustc development, where you are actually changing the rustc binary, but our incremental compilation infrastructure isn't necessarily designed to handle that case with complete fidelity.
I am still trying to tease out the scope of this bug. It is of course not good to have these ICE's affecting our internal tests. But I want to resolve whether the problems witnessed here represent bugs that should be resolved in some way within rustc (such as by versioning the incremental metadata, and ensuring that all source code changes to the compiler force one to disregard past incremental artifacts), or if they should be solely resolved in a manner local to our test suite (i.e. via changes to rustbuild to clear out portions of tmp/ directory more aggressively in response to certain compiler rebuilds.)
Activity
Aaron1011 commentedon Mar 20, 2021
@petrochenkov: I'm unable to reproduce this locally. Does this happen on the latest
master?Aaron1011 commentedon Mar 20, 2021
That test file isn't even a proc-macro crate, so I have no idea how
proc_macro_decls_staticcould ever return anything other thanNone.petrochenkov commentedon Mar 20, 2021
I'll try to reproduce this outside of the test suite and with #83314.
petrochenkov commentedon Mar 20, 2021
After clearing incremental cache for this test I cannot reproduce this either.
Although there probably was some legit reason behind the cache being corrupted, the reproduction is now lost so closing the issue.
Auto merge of rust-lang#83314 - Aaron1011:print-unstable-value, r=lcnr
petrochenkov commentedon Apr 3, 2021
I'm seeing this error again after updating the compiler/library from upstream and rerunning the test suite.
petrochenkov commentedon Apr 3, 2021
Another one from
src/test/ui/async-await/issues/issue-64964.rs(also disappears after removing the incremental directories):Aaron1011 commentedon Apr 3, 2021
The second issue seems like an issue with the incremental cache not getting invalidated when the compiler version is changed. Normally, that happens because the nightly compiler date changes, but I think it might not be happening with a locally built compiler (since the version suffix is always
-dev). I don't think it has anything to do with the original issue.petrochenkov commentedon May 14, 2021
Status update: I haven't seen these errors recently.
the8472 commentedon May 19, 2021
I saw these today after rebasing to f94942d but running
./x.py cleansolved it.ui test errors
Mark-Simulacrum commentedon May 20, 2021
Also observed these today - https://gist.github.com/Mark-Simulacrum/00eb855785b8cd9d8a696eb9b8fc1317
pnkfelix commentedon May 21, 2021
A note: This bug has evolved quite a bit from its original filing.
Many of the reported issues are not specifically about fingerprints.
A common theme among them is that they are all problems that arise on the
x.py testui test suite.A recent discussion with @Mark-Simulacrum leads us to think that this may be very specific to local
rustcdevelopment, where you are actually changing therustcbinary, but our incremental compilation infrastructure isn't necessarily designed to handle that case with complete fidelity.I am still trying to tease out the scope of this bug. It is of course not good to have these ICE's affecting our internal tests. But I want to resolve whether the problems witnessed here represent bugs that should be resolved in some way within
rustc(such as by versioning the incremental metadata, and ensuring that all source code changes to the compiler force one to disregard past incremental artifacts), or if they should be solely resolved in a manner local to our test suite (i.e. via changes torustbuildto clear out portions oftmp/directory more aggressively in response to certain compiler rebuilds.)petrochenkov commentedon Feb 15, 2023
I haven't seen this issue for very long time despite still using the test suite regularly.