Change:
I just tried a basic wasm project: and compiled with . This worked with the nightly from 2020-06-13. However, now I get a linker error: It looks like spaces in the path aren't handled correctly. I installed Rust using the msi installer and then unzipped the wasm32-unknown-unknown standard library in the correct folder. Does someone know what changed in the past three months? Otherwise, I can check in-between versions to narrow down the regression. I can still build for x86 and thumbv7m targets without a linker error. : I'm using Windows 10 64-bit.
I checked more versions and found the nightly introducing the issue: Good: Bad: I see that LLVM was upgraded from 10 to 11 in that nightly. Was this a regression in LLD?
Let’s bisect this. ping cleanup Commit range for the regression would be ...
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup 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
Assigning as discussed as part of the and removing . Would be great, though, to gain a bit more insight about this issue. Feel free to adjust priority upon closer investigation.
I did some evaluation with and it looks like this issue may be a 32-bit Windows specific. found no regressions in the commit range to using the provided code sample on my 64-bit Windows machine as well as no regressions on my 64-bit Linux machine.
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
Given that the linker input string contains I have no reason to believe Rust is doing anything wrong and that it is LLD which is at fault here. Someone should debug LLD and figure out where those strings are getting split up incorrectly.
We did a bit of a deeper dive than expected into this bug during this week's T-compiler planning meeting. The relevant portion of the log starts at around Investigation is ongoing
Summarizing from the Zulip discussion: I believe this was introduced by , which fixed parsing "response files" ( indicating 's contents should be inlined in the command-line arguments), to use the encoding style of the host platform instead of hardcoding "GNU". But our code still outputs the GNU style, even on Windows, and that's why it breaks. I expect all we need to do is pass here (these are arguments passed outside of the file): Alternatively, we could try and come up with an escaping method that is a superset of the two implemented variants: Then it wouldn't matter what style is expected, it would always be correct. I believe our Windows escaping would be valid everywhere, at least from briefly reading the comments in the snippet above, so we could just always use that.
assigning self to figure out if this is also a stable-to-beta regression, and if so, identify a beta-backportable fix.
(yes, it affects beta, and basically breaks LDD usage on windows, which means it breaks wasm32-unknown-unknown targets on Windows.) Upgrading priority to P-critical to reflect importance of addressing this. (Luckily has already outlined some reasonable solutions, as discussed above.)
Hurm. My local windows virtual box ran with in the , and the resulting set up ... does not exhibit the problem. :cry: I haven't dug deeply into why it doesn't reproduce the problem, beyond checking the recent git log info for llvm and for rust to see if anyone secretly fixed this. My main point in reporting this here is to say that I am not confident I'll be able to fix the bug if I cannot reproduce it via a local build.
I've posted which I think applies suggestion (I haven't tested that code). I will work on getting a try build which folks who can reproduce could then test.
or someone else who can reproduce this, could you try the try build? You should be able to use the following:
I installed from these URLs: And worked without an error so it does seem to be fixed.

Discussion:
LldFlavor::Link => "link", LldFlavor::Ld64 => "darwin", }); <ins> if let LldFlavor::Wasm = flavor { // LLVM expects host-specific formatting for @file // arguments, but we always generate posix formatted files // at this time. Indicate as such. c.arg("--rsp-quoting=posix"); } </ins> c } };