Change:
from time import time <ins> # Acquire a lock on the build directory to make sure that # we don't cause a race condition while building # Lock is created in `build_dir/lock.db` def acquire_lock(build_dir): try: import sqlite3 path = os.path.join(build_dir, "lock.db") try: con = sqlite3.Connection(path, timeout=0) curs = con.cursor() curs.execute("BEGIN EXCLUSIVE") # The lock is released when the cursor is dropped return curs # If the database is busy then lock has already been acquired # so we wait for the lock. # We retry every quarter second so that execution is passed back to python # so that it can handle signals except sqlite3.OperationalError: del con del curs print("Waiting for lock on build directory") con = sqlite3.Connection(path, timeout=0.25) curs = con.cursor() while True: try: curs.execute("BEGIN EXCLUSIVE") except sqlite3.OperationalError: pass return curs except ImportError: print("warning: sqlite3 not available in python, skipping build directory lock") print("please file an issue on rust-lang/rust") print("this is not a problem for non-concurrent x.py invocations") return None </ins> def support_xz(): try: with tempfile.NamedTemporaryFile(delete=False) as temp_file:

Discussion:
I tried this: src/test/ui/fn/issue--no- I expected to see this happen: the test suite is run, possibly building the testsuite binary using the existing stage 1 . Instead, this happened: the stage 1 is rebuilt before running the test suite. This seems to happen randomly; I had rerun the test suite quite a few times using the same command with no issues. This is rather inconvenient since even with 16 logical cores, building takes several minutes and grinds my machine to a halt. This doesn't just seem to happen when running the test suite, but I'm less confident about saying that rebuilds after modifying rustc's codebase are spurious. modify labels +A-contributor-roadblock +A-rustbuild
Can you try running with CARGO_LOG=cargo::core::compiler::fingerprint=info and provide a build log when you see a spurious rebuild?
Got one [ended after seeing it was building to spare my poor swap space]: <details<summaryLog</summary</detailsAlso encountered an ICE that I'll file a bug report for ().
cc any idea on what could be causing the nothing obvious fingerprint error here? Or how to debug it?
It looks like this has to do with: is this a case where a flag is used to track rlib/rmeta files, and the sysroot files are changing somehow? Are those files indeed missing? Or maybe they're linked in at a later stage of rustbuild?
Hm, yes, we're definitely tracking sysroot files, but they shouldn't be missing - can you check whether those files are actually present? Do you perhaps have something like x.py check running from your editor in the background?
That file does seem to exist. I am running via rust-analyzer, so that may be part of the issue.
I think this is a duplicate of

Since I started using vscode, it is now often the case that the which vscode runs is still not done when I alt-tab back to my terminal to do (for example) . That regularly leads to errors like this: In those cases, just running again solves the problem -- but it would still be better if having vscode run in background would not break what I do in the terminal. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
So there's several solutions to this: Don't support this, tell people to run x.py check in a different directory so the build directory goes elsewhere. Add a global lock like Cargo's on the build directory Specialize x.py check to use different sysroot for stage0 - i.e. don't fix x.py build and test running simultaneously etc I am interested in hearing which you think would be preferable. Cc
If they could run truly in parallel that would be great. However, a separate build dir also means the bootstrap rustc is downloaded again, right? That would not be great.
Yes, option 1 would duplicate the stage0 rustc downloads. Option 3, though, would not - it's probably the right choice I think since x.py check is somewhat unique in being the most likely to be invoked in parallel.
in an ideal world, would fixing also fix this?
Not really. It might even make things worse. rustbuild uses the same stamps for both check and build steps (and sysroots etc) so when both are running simultaneously we will stomp all over the other, which is going to lead to incorrect behavior.
I was not able to replicate this. On my machine running both in parallel gives
Ok, I figured out when this happens: you need one terminal to be building the compiler while the other is building libstd. If both are building libstd this error doesn't show up.
I think this can also lead to losing the build cache... at least I just had a case where after showing this error, it then (on the next attempt) proceeded to rebuild the crate graph rustc depends on, instead of just the crate that I changed.

FYI option 3 was seen as too big a hammer in ; the proposed fix was to use a build lock on the sysroot instead, the same way cargo has a build lock for .
I think that's not quite accurate, in the specialization was too specific (i.e., the problem is more widespread, any two x.py runs can touch shared files currently). "Insufficiently big hammer" is probably the right description of option 3.
claim
I am afraid this is still not working properly: when I run in the terminal while there is a vscode running in the background, I get but once vscode is done, all that happens is that the in the terminal starts using 100% CPU. It does not actually start running though.
Ah: looks like it missed actually breaking out of that loop -- happy to accept a PR to do so.
is that something you could take a look at?