-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustc panicked at 'LocalTableInContext: key not found', libcore/option.rs:960:5 #51798
Comments
If I use cargo doc I get a different stack trace:
|
The crash stopped occurring in my code when I fixed an invalid import: |
I'm pretty certain this is caused by rust/src/librustc_privacy/lib.rs Line 798 in e3bf634
But, really, it'd be nice to have a reduced test case so we can confirm the bug is fixed afterwards. |
Makes sense. I'll try to pare it down to something useful. |
I'm failing to reproduce this crash without using multiple crates, so I can't figure out how to put it in a Playground example or Source
|
Okay, I've got the failure occurring in a compiler test at jeremyBanks/rust@b9fa771.
#![crate_name="rust_issue_51798_example_child"]
#![crate_type = "lib"]
pub fn vec() -> Vec<u8> { vec![] }
Result:
If I understand correctly, it will be possible to turn this into a regression test by annotating it with the desired non-panic output, once this issue has been fixed and we know what the fixed output looks like. But since we're not sure what the will look like, there'd be no point trying to get this merged yet. |
Always check type_dependent_defs Directly indexing into `type_dependent_defs` has caused multiple ICEs in the past (#46771, #49241, etc.) and is almost certainly responsible for #51798 too. This PR ensures we always check `type_dependent_defs` first, which should prevent any more of these (or at least make them easier to track down).
@jeremyBanks: now that #51882 is merged and should be in the next Nightly, could you check your test-case again to see whether it's fixed? I didn't have time to add your test case before it was merged. Thanks! |
@varkor I think it's fixed. My stand-alone test case produces the same initial error message of "no type-dependent def for method call", but it no longer displays any panic; it seems to exit cleanly. Using
Using
(Now running in a normal Debian VM. Sorry for the constantly-changing platform. :P) |
Sorry! I didn't mean to submit the post yet, or close the issue, but I mis-clicked. I'm still trying to figure out the appropriate annotations to make this pass as a |
@jeremyBanks: yes, a regression test would be useful here. Actually, I don't think the behaviour is even correct here — it shouldn't be displaying that error at all, even if it's not actually crashing. |
Did a test ever get added here? |
Add more regression tests Closes rust-lang#39618 Closes rust-lang#51798 Closes rust-lang#62894 Closes rust-lang#63952 Closes rust-lang#68653 r? @Centril
I'm sorry, I haven't reduced this at all, and I'm sure the code is awful, but the error message said you'd appreciate a bug report.
I tried this code:
jeremyBanks/0dmg@ae3b7d2
using
cargo clean && RUST_BACKTRACE=1 cargo run --verbose
I expected to see this happen: my program would run, or the compiler would give one of its typical helpful error messages!
Instead, this happened:
Meta
I am using the Windows Linux Subsystem thing with Debian or Ubuntu, I think.
rustc --version --verbose
:cargo --version --verbose
:Backtrace:
The text was updated successfully, but these errors were encountered: