Open deprilula28 opened 2 years ago
The panic happens on the second .unwrap()
at https://github.com/rust-lang/rust/blob/9dbbbb12c0b796f35cbf5a518ac12846c969a214/compiler/rustc_monomorphize/src/collector.rs#L903
According to the docs of Instance::resolve
this should be impossible:
Returns Ok(None) if we cannot resolve Instance to a specific instance. For example, in a context like this,
fn foo<T: Debug>(t: T) { ... }
trying to resolve Debug::fmt applied to T will yield Ok(None), because we do not know what code ought to run. (Note that this setting is also affected by the RevealMode in the parameter environment.)
Presuming that coherence and type-check have succeeded, if this method is invoked in a monomorphic context (i.e., like during codegen), then it is guaranteed to return Ok(Some(instance)).
The error doesn't specify where in the code caused the issue, making it hard to provide an example.
Is this a public project? If so can you tell which project it is and what commit? Do you roughly know what you last changed before this crash? If it isn't public you could try making a minimal reproducing example. https://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/ is a great post about how to reduce it. You could also try rust-reduce and if you inline all modules creduce. While creduce is written for C, most of the transforms it does work pretty well in any language with a C like syntax, including Rust.
It is possible that someone can find the issue without a reproducing example, but providing one will make finding the issue much easier.
@deprilula28 is this issue still relevant? If you can't provide a minimal reproducible example, could you please test with a recent rustc and see if the problem is still there?
Triage: Relabeling issues which don't have a runnable reproduction (as opposed to having a non-minimized one) to the new label S-needs-repro. @rustbot label +S-needs-repro -E-needs-mcve
Code
The error doesn't specify where in the code caused the issue, making it hard to provide an example.
Meta
rustc --version --verbose
:It also happens on stable and an on 1.55.0 (which I updated from after I initially ran into this problem).
Error output
Backtrace
``` stack backtrace: 0: 0x7fff5d2b8c6f -::fmt::hda2ead71f9ecd977
1: 0x7fff5d2e2eba - core::fmt::write::h8a2c40ddb66ccc71
2: 0x7fff5d2ab438 - ::fmt::h94c9e1851482e651
3: 0x7fff5d2bc1b6 - std::panicking::take_hook::ha134472c0530875e
4: 0x7fff5d2bbc9c - std::panicking::take_hook::ha134472c0530875e
5: 0x7fff45f7b12e - ::check_crate_post
6: 0x7fff5d2bcac9 - std::panicking::rust_panic_with_hook::h1142463f499f4e70
7: 0x7fff5d2bc53f - rust_begin_unwind
8: 0x7fff5d2b9597 - ::fmt::hda2ead71f9ecd977
9: 0x7fff5d2bc4c9 - rust_begin_unwind
10: 0x7fff5d317460 - core::panicking::panic_fmt::hc1b1ca620e7a2c9f
11: 0x7fff5d3173ac - core::panicking::panic::hfef5cee9afdef02a
12: 0x7fff4857a3c9 - ::visit_terminator
13: 0x7fff4857d0e7 - ::visit_impl_item
14: 0x7fff4857622c - ::fmt
15: 0x7fff4857653e - ::fmt
16: 0x7fff4857653e - ::fmt
17: 0x7fff4857653e - ::fmt
18: 0x7fff4857653e - ::fmt
19: 0x7fff4857653e - ::fmt
20: 0x7fff4857653e - ::fmt
21: 0x7fff4857653e - ::fmt
22: 0x7fff4857653e - ::fmt
23: 0x7fff4857653e - ::fmt
24: 0x7fff4857653e - ::fmt
25: 0x7fff4855da0f - as rustc_privacy[4b5d474e1e41ebc0]::VisibilityLike>::new_min
26: 0x7fff48574752 - ::fmt
27: 0x7fff4857215d - ::internalize_symbols
28: 0x7fff49809ad3 - ::error
29: 0x7fff497b0103 - ::try_mark_green
30: 0x7fff496f917c - rustc_query_impl[fc0b1a80fdfefbde]::profiling_support::alloc_self_profile_query_strings
31: 0x7fff495837cc - ::initialize_start_block
32: 0x7fff4963343a - ::initialize_start_block
33: 0x7fff4974c10e - ::try_mark_green
34: 0x7fff49939e85 - rustc_codegen_ssa[e9091bef2ee1db53]::back::symbol_export::crates_export_threshold
35: 0x7fff49807406 - ::error
36: 0x7fff4979d20a - ::try_mark_green
37: 0x7fff496f8c48 - rustc_query_impl[fc0b1a80fdfefbde]::profiling_support::alloc_self_profile_query_strings
38: 0x7fff49551c30 - ::initialize_start_block
39: 0x7fff496056d3 - ::initialize_start_block
40: 0x7fff49b3e92b - ::encode_alloc_id
41: 0x7fff49b52916 - rustc_metadata[1b6d4e0ca9c23e9d]::rmeta::encoder::encode_metadata
42: 0x7fff49bdb095 - ::decode_alloc_id
43: 0x7fff49b51f73 - rustc_metadata[1b6d4e0ca9c23e9d]::rmeta::encoder::encode_metadata
44: 0x7fff460f3f8c - ::link
45: 0x7fff460db2ff - ::ongoing_codegen
46: 0x7fff45fdb0b6 - ::fmt
47: 0x7fff45f95096 - rustc_driver[c696c68206e0209d]::pretty::print_after_hir_lowering
48: 0x7fff45ff7386 - ::fmt
49: 0x7fff45f9e853 - rustc_driver[c696c68206e0209d]::pretty::print_after_hir_lowering
50: 0x7fff460166d8 - ::fmt
51: 0x7fff5d2c97fc - std::sys::windows::thread::Thread::new::h0fc50b675267fa21
52: 0x7fffd8e854e0 - BaseThreadInitThunk
53: 0x7fffda38485b - RtlUserThreadStart
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.58.0-nightly (495322d77 2021-11-08) running on x86_64-pc-windows-msvc
note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C linker=rust-lld.exe -C incremental -C link-arg=-fuse-ld=lld --crate-type lib
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
#0 [collect_and_partition_mono_items] collect_and_partition_mono_items
#1 [exported_symbols] exported_symbols
end of query stack
```