Change:
hasher.write(src.as_bytes()); if hasher.finish::<u128>() == self.src_hash { <del> *src_kind = ExternalSourceKind::Present(src); </del> <ins> *src_kind = ExternalSourceKind::Present(Lrc::new(src)); </ins> return true; } } else {

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --The setup under which this occurs is somewhat complicated, but I'll try to reduce it as much as I can and update this issue with details. But basically it's using the latest nightly rustc and running on the latest code (, rev ). <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: (See full output in the backtrace details below) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Also to note: so far this has happened 2/2 times today. It didn't happen yesterday (which presumably was running using a slightly-older rustc and checking slightly-older glean code).
Re-running the command: in the proper directory on the machine in question reproduces the error. The file it's complaining about () exists and doesn't appear corrupted.
Running the command over and over changes which crate it errors out on. In the initial run it was erroring out on but on subsequent runs it changes to , , etc.
If I remove the bit then it works fine. So seems related to the save-analysis code. /cc
I'm able to reproduce this in a local environment as well. Minimal steps so far (on a Ubuntu 18.04 VM) I ran with and the specific invocation that's reliably reproducing the failure is: (Obviously your paths may vary) Also note that this does NOT happen with (which installs a rustc built on 2020-03-09) so it's a regression between rustc version and rustc version .
Rust regression range:
If you're unable to repro or need more detail feel free to let me know. Otherwise for now I'm leaving this with you (i.e. rust developers) to dig into.
I have the very same crush with rustc 1.43.0-nightly ( 2020-03-11) on both of Mac and WSL2/Ubuntu, every time Rust language Server starts up in VSCode.

No problem in rustc 1.43.0-nightly ( 2020-03-01). ### Error message:
I used to narrow the range to ...
Therefore regression from , cc
cc
I'd say this is a pre-existing save-analysis bug that was exposed by . should handle source files missing, which might require to return .
Same here:
Actually, this doesn't have to fail at all either, it's just hardcoded to non-external files: Before checking for the source, it would need to do this: And then something like this to handle both local and external sources: EDIT: nevermind about that last part, it's already.
So what are next steps here? I don't know what rustc's policy is with respect to regressions, is the regressing patch author responsible for fixing the regression?
Downgrading to fixes the issues in the vscode plugin for now.
Sorry, I'll go implement now. EDIT: up at .
I'm not sure why the original reproduction seemed so daunting, it triggered the bug as expected. I was also able to reproduce it on the problem crate itself: and it succeeds with this (which is my local build including ): also gets past the ICEs, but I can't easily do a full build because build scripts failed.
Thank you for the fix! At the moment using rustup to pull a nightly still gives me an older nightly (due to newer ones missing various components) but once I can get a nightly with the fix I'll report back whether or not it solved my original issue.
Confirmed the fix by forcing a nightly update. Thanks!
I am running into this / similar issue when is used as dependency: versions Here is the simple reproducible test case
Never mind I see now that version I have is . If I I do force update it works.