Retry opening proc-macro DLLs a few times on Windows.

[michaelwoerister]

On Windows, the compiler sometimes fails with the message error: LoadLibraryExW failed when trying to load a proc-macro crate. The error seems to occur intermittently, similar to #86929, however, it seems to be almost impossible to reproduce outside of CI environments and thus very hard to debug. The fact that the error only occurs intermittently makes me think that this is a timing related issue.

This PR is an attempt to mitigate the issue by letting the compiler retry a few times when encountering this specific error (which resolved the issue described in #86929).

[rustbot]

r? @petrochenkov

(rustbot has picked a reviewer for you, use r? to override)

[petrochenkov]

@bors r+

[bors]

📌 Commit 227b285 has been approved by petrochenkov

It is now in the queue for this repository.

[kennykerr]

What does GetLastError return when LoadLibraryExW fails?

[michaelwoerister]

@kennykerr and I discussed this a bit. The underlying OS error is ERROR_NOACCESS which can have many causes. I also doubled-checked that Cargo does not try to pipeline proc-macro crates with other crates consuming them, so if there is a race between the linker still accessing the DLL and a downstream rustc process trying to load it, it would be due to some file system oddity and not because Cargo doesn't synchronize this properly. It's unlikely that a file system on a local computer would exhibit such behavior, but I could imagine that the situation is different in an CI environment where file systems are mounted via network or something like that.

I'll continue to investigate, trying find out what exactly is underneath the ERROR_NOACCESS.

[rodrigorc]

I've seen this behavior sometimes elsewhere with Windows systems. While I never found out why, I always suspected the antivirus (or Windows Defender or whatever there is), that sees a. EXE/DLL appear from thin air and thinks it has to be checked before it is allowed to be used.

[michaelwoerister]

We've been investigating this further. So far it looks like the mitigation implemented in this PR does not really help.

However, we noticed that all failures occurred in a setup where cargo/rustc were running inside of a Windows docker container, using a target directory that is shared between the host and the container. Moving the target directory to a folder that is not visible to the host seems to resolve the problem (though further testing is needed).

So it might be that a virus scanner or something else running on the container host might be the culprit here.

[mati865]

Moving the target directory to a folder that is not visible to the host seems to resolve the problem (though further testing is needed).

So that directory is not shared? Then this could also be an issue with sharing mechanism which is not uncommon.