-
Notifications
You must be signed in to change notification settings - Fork 13.3k
failed to lookup SourceFile
in new context
#92163
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Avoid cleaning specific crates since latest `rustc` nightly presents issues whith the disk cache when doing a clean of a specific crate as reported [here](rust-lang/rust#92163). This affects only the devnet scripts and would make the CI to take longer to run these scripts.
Avoid cleaning specific crates since latest `rustc` nightly presents issues with the disk cache when doing a clean of a specific crate as reported [here](rust-lang/rust#92163). This affects only the devnet scripts and would make the CI to take longer to run these scripts.
@Mark-Simulacrum: Do you know why this didn't show up in the rust-timer perf runs that I did for that PR? |
We didn't used to show errors on comparison pages (only by omission), I think at least part of the webrender results were missing. I just today landed a PR that addresses this, so we should hopefully notice this sooner in the future, and you can see that results from #91924 now have a line at the top indicating this breakage. It should also get reflected in future PR comments and such. |
I have a fix locally, and I'm working on a PR. |
One thing I'm realizing -- we should list fixed benchmarks on rustc-perf as well. I'll file an issue for that. |
I have come across this problem on my own machine. Please note I am using sscache.
Here is where it got to: pub unsafe fn init() {
let (_engine, _engine_path) = open_library_srv!("engine").expect("Failed to open engine shared library!");
extern "C" fn __process_voice_data(client: *mut std::ffi::c_void, len: i32, data: *mut std::os::raw::c_char, xuid: i64) {
unsafe {
if crate::record::SV_BroadcastVoiceData(client, len, data, xuid) {
BROADCAST_VOICE_DATA_DETOUR.get().call(client, len, data, xuid);
}
}
} |
Still occurs on |
This is a temporary measure while we wait for rust-lang/rust#92163 to be resolved.
This is a temporary measure while we wait for rust-lang/rust#92163 to be resolved.
This is due to a recently-introduced conditional compilation ICE (rust-lang/rust#92163).
FWIW, it prevents building clippy with |
Seeing the increasing number of incoming reports, we raise the evaluation of this issue @rustbot label -P-high +P-critical |
…cjgillot Import `SourceFile`s from crate before decoding foreign `Span` Fixes rust-lang#92163 Fixes rust-lang#92014 When writing to the incremental cache, we encode all `Span`s we encounter, regardless of whether or not their `SourceFile` comes from the local crate, or from a foreign crate. When we decode a `Span`, we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate, then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion, when we try to resolve definitions from other crates. In certain cases, however, we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate, leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding, we call `imported_source_files()` when we encounter a foreign `CrateNum`, which ensure that all `SourceFile`s from that crate are imported into the current session.
rustup The previously pinned toolchain was affected by rust-lang/rust#92163, let's switch to one where that problem is fixed.
Now that the issue in nightly `rustc` reported [here](rust-lang/rust#92163) is fixed, allow the devnet scripts to only clean the `nimiq-genesis` crate.
Now that the issue in nightly `rustc` reported [here](rust-lang/rust#92163) is fixed, allow the devnet scripts to only clean the `nimiq-genesis` crate.
This issue is milestoned 1.59, but I've also been running into this crash on 1.58.1 stable. |
84f962a (based on bisection) made rustc-perf's CI start failing on the webrender-wrench benchmark, with this error. Not sure what is making rustc-perf special here, but it's also failing on the collector.
This can be reproduced with the following:
cc @Aaron1011
The text was updated successfully, but these errors were encountered: