Change:
E.g. on <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Cannot reproduce on . Maybe check you systems again.
The failure happens on a Windows 7 x64 machine. I reproduced this on another machine running Windows 7 x86, this time with toolchain.
I don't have any Windows machine to test (left alone Windows 7 which not available on CI). All builds on Windows 10 with msvc and gnu toolchain succeeded: Let's ping Windows group to see if any folks can verify the issue: ping windows
Error: Only Rust team members can ping teams. Please let know if you're having trouble with this bot.
ping windows
Hey Windows Group! This bug has been identified as a good "Windows candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Speaking for the Windows team at Microsoft, Windows 7 has reached . We're not interested in providing any further support for Win 7 development. We (and members of the Rust community) are also actively working on , which would officially deprecate some older Windows platforms (those that are EOL) for Rust. I realize that this position may not be satisfying. However, we have to draw the line somewhere on supporting old versions of OSes, and Windows 7 has reached its official EOL. You may still be able to target Windows 7, by cross-compiling (compiling on a modern Windows version, or by compiling on Linux targeting Windows).
Also, you might check whether you have any anti-virus products installed. If so, try disabling them, or at least adding an exception that covers your development tree. Sometimes "permissions" problems are caused by anti-virus products opening and scanning executable files.
Apparently, Windows 7 is still a , so even though it's EOL for Microsoft, Rust still has to support it. It seems that maybe we should reduce Windows 7 to a lower tier at some point soon.
I would like to point out that according to , Windows 7 is used by 23% of Firefox users. Microsoft also offers paid extended security updates through January 2023 for Windows 7 which may be actually used in enterprise environments. I think it's too early to drop support for Windows 7. That said, this particular issue feels like an issue with anti-virus. could you check whether this issue occurs with an antivirus product disabled?
im having the same issue, i also use windows 7 x64. and don't have any anti virus installed
I've already checked and eliminated that from the list of possible causes along with any possible system issues I could think of. The problem appears on two machines with different hardware and software, one of which had a fresh installation of Rust toolchain via rustup and the issue appeared instantly. There's not much I can draw from that cargo log. By the looks of it the issue happens with crates that depend on and use proc-macro crates. In some cases doesn't trigger it but does.
using RUSTCLOG=debug
and just a blind shot, IIUC the error suggests there's an issue when tries to write on those volumes ( and ). Does the user executing have proper permission to those volumes? Does the error happens intermittently or it is always reproducible?
The commit range includes the update of LLVM submodule , so it is probably caused by one of:
Permission denied sometimes means another process has an open handle to the file. has been useful to me in tracking down similar issues, which turned out to be an antivirus product in my case.
Downgraded to nightly-2021-01-12, compilation is successful again.
There are no issues with permissions on both machines... The error is always reproducible.
I encountered the same problem when upgrading the latest version. After downgrading this version, everything works fine again.
The issue title downplaying the problem a bit. nightly-2021-01-14 and onward is unable to compile any library crate. I.e. running on an empty gives the same This makes rustc effectively unusable on windows 7. (except for binaries with zero non-proc-macro dependencies) Here's what's happening, per process monitor: ! I am neither windows, nor LLVM expert so i cannot really interpret it, but to transcribe what's happening (judging purely by the names of the winapi calls): On stable: we create the temporary write to it SetDispositionInformationFile(Delete = False) (??) rename it to very straightforward On nightly many more things are happening and i'm not sure why: We create the temporary Open it and immediately close, multiple times with different arguments (??) SetDispositionInformationFile(Delete = True) (????) (!!!) Write to it QueryOpen it, get told that DELETE_PENDING give up. Oh, and implied, but did not explicitly mention, the regression happened in .
(Not sure if i have permission to do this, but..) modify labels: +I-prioritize
Let's ping llvm
Hey LLVM ICE-breakers! This bug has been identified as a good "LLVM ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
I haven't look super closely but I think it might be related to The rollup linked as the regression above did include an LLVM update (). It updated the LLVM submodule from rustc/11.0-2020-10-12 to rustc/11.0-2021-01-05 which brought along
I tried building rustc with rust-lang/llvm-project reverted and that makes rustc work again. However I have no idea what that commit is doing, so am absolutely not comfortable filing that upstream.
Thank you so much for the investigation work! Assigning as discussed as part of the and removing .
This is now regression-from-stable-to-beta. Can we please rename the issue to something more alarmist a-la "Starting with 1.51, rustc is no longer usable on Windows 7"? Current title is fairly nonspecific and implies that the problem is localized to some crates, when in fact it affects pretty much every crate, but instead localized to OS.
label -regression-from-stable-to-nightly regression-from-stable-to-beta A-LLVM
Can someone on Windows 7 debug-step through LLVM's and see where the actual error arises? I'm interested in which Windows API call returns the error, and the full backtrace from that point. I also wonder if this can be reproduced with Clang 11.0.1.
setDeleteDisposition is called [at least] twice. First call succeeds with no incident. Second call fails at the returns zero and gives 13 ERRORINVALIDDATA (i think.. At least EC variable is set to it's tricky to catch result itself, as it's elided in the debugger. But my reading of is that it should forward the error code value transparently) The full backtrace at that point is: <details</detailsAnd the locals at the couple deepest frames (although this doesn't seem to be very useful) are: <details<summary</summary</details<details<summary</summary</details<details<summary</summary</detailsSame (single) winapi call as seen by procmon (i'm not sure why it translates to 4 "Operation"s): ! P.s.: the first (successful) happens at <details<summarybacktrace</summary</details
Since it's coming from calling , I wonder if it could be reproduced with clang objects and , which calls the same. Also, this bug looks similar using :
does indeed fail with the same error:
assign discussed at . Assigning to to own revert of cherry-picked commit and file issue to track fallout of such.
Hi, any progress on fix?
I opened rust-lang/llvm-project to start, a simple revert which reportedly fixes this issue --
I just want to confirm that the fix is in nightly, and it's working! Thanks,
But while it not applied to beta, it can't build rust with , as it download beta files from 2021-02-14, or maybe i do something wrong.
Either setting your to have or setting in your should work P.s.: correction: for some reason method does not work for me, but the does. Although now that I re-read your message, i'm not sure if would further impact this. I.e. I don't know if the llvm on ci has the fix commit or not. But then again, seems to do nothing for me, as in I'm trying to run and it's currently rebuilding llvm from source anyway, so..
I'm not sure how that download is updated, but the PR is beta-nominated, so once that's approved we can backport it to the beta branch and then update master . Hopefully that will sort it out!
Normally we only do so once a cycle, but we're happy to accept PRs if there's some reason to update it outside of that.
See to track long-term resolution between Windows 7 and the reverted bug fix.
Hello! I've fixed the issue in LLVM in - please let me know if the issue is still there in the next code drop.
Thanks I don't have access to test this myself, but hopefully the Windows 7 users here can try it out. Let's collect further feedback on the new open issue, .

Discussion:
<del> Subproject commit 2a054c1e4fb04756b7f0509eeae63289db0df887 </del> <ins> Subproject commit 96ae8953e4938d39c4173dd189f268459fff8c02 </ins>