Open voltagex opened 1 year ago
Writing the final binary is the responsibility of the linker (in this case MSVC's link.exe
) so not something Rust controls.
One thing you can try is opening up a native tools command prompt and compiling a simple C program using cl.exe
. Does that have the same issue? If so you may need to report a minimal repo to the Visual Studio team.
Bingo! (unfortunately)
Writing a hello world and compiling it with cl.exe inside the shared folder results in the same issue.
"Our teams prioritize action on product issues with broad customer impact" sounds remarkably like "too niche, wontfix". Can the rustc detect and warn about this scenario? Maybe that's too niche, too.
Honestly that sounds like boilerplate to me. It's marked as under consideration so I do think it's worth waiting a bit to see if there's any decision.
I guess Rust could test the output file for the magic bytes that indicates an executable file (or at least that they're non-zero). But that might need a new issue to gather feedback on that plan.
Testing this on Windows 10.0.19045.2846, Windows Sandbox and Hyper-V enabled.
The next steps should be done inside the sandbox.
Install Rust via rustup-init.exe. This will also pull down a "minimal" Visual Studio (sidenote: you can add a flag to your VS setup invocation to make it run without user input, but still show what it's doing)
Close the Visual Studio windows that are launched (?) so that rustup-init continues.
Then try creating a new application and add proc-macro2 to its dependencies (this does not just impact this package, it'll be anything that uses build_script_build.exe IMO). Note that I am using the shared folder here.
If I create a new directory that IS NOT shared and create a new application
Now, the most interesting part of this:
.exe files created in the shared folder, e.g.
C:\test\build-test\target\debug\build\proc-macro2-367b58302398b1c3
are zeroed. the .d file and the .pdb seem to be fine though!build-test.zip cargo-build-msvc-link.zip - procmon trace, stable
I first noticed this on stable, reproduced here with
I believe this to be an issue with the way Windows Sandbox shared folders work but it needs someone with more experience in both Windows and Rust to have a look.
This may need to be re-tested on Windows 11 as well.
[Edit: I can't reproduce this with the GNU toolchain!]