-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
failed to lookup SourceFile
in new context
#92163
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: