Change:
Error happened while working on updating closure capture analysis in rustc which is part of rustctypeck. The highlighted line is what changed between the build that broke and the build before it. <!-- 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. --Version reported in build log and similarly one or two more Complete build log: Build log with : Build directory: (Heads up, this is 29G tar, 39G extracted)
What was the exact build command that caused the ICE? If this is with , then I also see this issue every now and then. Locally built rustc all have the "dev" version string, which means it doesn't have to rebuild everything just because you do , but it also means it cannot detect that the ABI changed, so it might try to load old files with the new rustc and of course that will fail. I am not sure if much can be done about this.
Some potential duplicates: , , ,
I do . This happened to me again last night: The assertion is fired in the not the same line but the same file, I haven't gotten around looking at the query code to see what failed. Only thing I worked on since the last x.py clean (maybe 10-15ish builds in, though I could be wrong) was change closure/generator pretty printing (in rustcmiddle/src/ty/print/pretty), haven't rebased since. Though I can see that rustc builds are themselves are more prone incr compile errors, also didn't think had anything to do with the build process, otherthan maybe some version strings.
Cc I mentioned because one way to avoid this problem might be to embed the git commit in the version string used for rebuild detection -- but that would be rather annoying in many cases.
You can set ignore-git to false in and that'll embed git commit hashes. But I think that must only patch over bugs - it can't be necessary. I doubt it will fully fix this bug. I suspect the problem is that Cargo doesn't delete incremental state on dependency changes - which means that rustc must be prepared, currently, to see incremental state serialized by a different rustc... ideally, handling that in a way that doesn't just throw everything out, but even just not panicking would probably be enough.
See also
The proper way to fix this is to wipe the build cache whenever the stage1 compiler changes. That will make builds a lot slower, but it's better than ICEs and having to wipe the cache anyway. I guess we could add a --keep-stage1-cache flag if you're sure you haven't touched metadata - not sure how useful it would be in practice. said on Zulip:
Wait, I'm confused again. Why does the metadata matter other than the incremental cache? Cargo already invalidates the cache when is modified, which is why libstd gets rebuilt when you modify the compiler. Is there anyone not using that's been hitting this issue?
I found while working on that this is not true: if you use --keep-stage-std 1, cargo will blithely keep the cache for all crates in build/stage1-rustc, without rebuilding. Copying over my comment from
Another possible fix is to make rebuilding after a commit cheap enough that we can include the hash unconditionally. Right now it's used in rustcsession; if we move it to rustcdriver, that would only need to relink the .so and recompile the final rustdoc/clippy/miri crates, not their dependencies. I guess it means we'd have to suggest using keep-stage-std more often :/ but people are doing that pretty frequently already.
Oh, and it has the downside that if you're testing the project on external crates cargo will recompile them after every commit. Maybe that's a good thing?
The only time it won't fully fix the issue is when you're modifying rustc_metadata or similar and don't make a commit between builds. I'm ok with not fixing that case, because anyone working on metadata is much more likely to understand what went happened and how to work around it than random contributors stumbling into this for the first time.
hit this issue this morning with incremental disabled, so it's relevant to all metadata loading, not just incremental.
Thanks for pointing me to the right issue. Following Tried some commits from the past few days Would it be useful to keep going with this approach? Oh, and this is with .
That's helpful, thanks! No need to find more commits, having a reproducer at all is already very useful.
This fundamental issue doesn't just apply to bootstrap, right? If one uses a locally built toolchain to build some crates, and then updates the toolchain, the same ICEs can arise (because the dependency rlibs will now be in the wrong format). Bootstrap is just where people run into it most often. But a solution inside bootstrap won't fix the fundamental issue. (E.g., it won't fix the Miri version of this problem, which got reported at )
Yes, that's right, any two toolchains that were built from different sources but have the same version string will have this problem (this is why we set a custom description by default in the source tarballs, so they won't reuse metadata from the official toolchain). Removing or defaulting it to would work for miri though, or at least make it so that you have to try a lot harder to run into the bug (e.g. twice with different local changes that haven't been committed).
A more "principled" fix would be to have something like a metadata version number embedded in the files that contributors are responsible for updating when the format changes. But I worry people will forget to update it, the same way people often forget to bump and that causes caching issues:
oh right, and suggested adding incremental to dep-info: but given that this bug is also showing up for metadata, not just incremental, I suspect that's not a complete fix:
Yeah, if we could somehow ensure that such a version number is always correct it would be a proper fix but manual bumping probably won't work. Unless we find a way to at least have CI fail when one forgets to bump...
reported seeing these crashes for , not just for tools and stage 1 rustc. I think he's running into this line being buggy: that shouldn't filter only to build, nearly all the commands read metadata and need the same treatment. Not making a PR because I don't have a test case yet, but if anyone comes up with an MCVE that makes crash, I'd be interested to see if this diff fixes it: also, I wonder if we could fix the original problem with metadata/incremental in stage 1 by applying clearifdirty to rustc too:
reproducer unfortunately gives me a different ICE than the one in the linked issue; it's for stage0, not stage1. So I can't use it to test my diff.
a while ago found that reproduced the issue; if someone could run that both with and without my diff applied to see if it makes a difference that would be helpful; I'm out of time for today.

Discussion:
cargo.env("RUSTC_TLS_MODEL_INITIAL_EXEC", "1"); } <del> if self.config.incremental { </del> <ins> // Ignore incremental modes except for stage0, since we're // not guaranteeing correctness across builds if the compiler // is changing under your feet. if self.config.incremental && compiler.stage == 0 { </ins> cargo.env("CARGO_INCREMENTAL", "1"); } else { // Don't rely on any default setting for incr. comp. in Cargo