Code change:
pub fn get_linker(sess: &Session) -> (String, Command, Vec<(OsString, OsString)>) { let envs = vec![("PATH".into(), command_path(sess))]; <ins> // If our linker looks like a batch script on Windows then to execute this // we'll need to spawn `cmd` explicitly. This is primarily done to handle // emscripten where the linker is `emcc.bat` and needs to be spawned as // `cmd /c emcc.bat ...`. // // This worked historically but is needed manually since #42436 (regression // was tagged as #42791) and some more info can be found on #44443 for // emscripten itself. let cmd = |linker: &str| { if cfg!(windows) && linker.ends_with(".bat") { let mut cmd = Command::new("cmd"); cmd.arg("/c").arg(linker); cmd } else { Command::new(linker) } }; </ins> if let Some(ref linker) = sess.opts.cg.linker { <del> (linker.clone(), Command::new(linker), envs) </del> <ins> (linker.clone(), cmd(linker), envs) </ins> } else if sess.target.target.options.is_like_msvc { let (cmd, envs) = msvc_link_exe_cmd(sess); ("link.exe".to_string(), cmd, envs) } else { let linker = &sess.target.target.options.linker; <del> (linker.clone(), Command::new(&linker), envs) </del> <ins> (linker.clone(), cmd(linker), envs) </ins> } }

Related discussion:
text: We're seeing this now in Rust because of (so my bad). is supposed to return the drive and path to the running batch file but that can fail if it was called with a quoted name. This isn't a new issue: Note that this can still be triggered on stable if the name of the batch file contains a space such as so reverting won't really help. What I suggest doing in this case is using instead which seems to work around the issue. It's also what you should be doing according to the  docs.
Marking as a regression from stable to beta, which I think is now true? Uncertain. Either way, I suspect we should consider this a compatibility note and close, since based on comment directly above people using this functionality should be doing so differently according to the Windows documentation.
This is an annoying regression though. Because instead of having to cfg only the name of the binary you now have to cfg all the places where you create / run the command because you need different args etc. We used the method below in our , but in the actual code the part is repeated a couple of times in different places. So this regression would result in more cfg boilerplate.
I would opt for a fix instead of closing with compatibility note based on the fact that problem is focused on windows 10 and nightly (not sure if it has already crawled into beta) with the original (stable) behaviour being desirable and this regression possibly affecting large number of crates but being hard to catch with cargo bomb (i suppose that not many crates run windows cmd scripts in their regression tests) You are essentially suggesting that crates / binaries implement a workaround. IMHO this is what stdlib is for (providing a portable abstraction) and client code should not be interested (or even aware) of the fine details of underlying implementation.
something like the following should work and as I mentioned should probably be done anyway. Is it? I haven't been able to reproduce any differences between Window 10 64 bit and Windows 7 32 bit in a VM. The Stack Overflow answer I linked talks about this in Windows XP so if there really is a difference between 7 and 10 then there might be a different bug. I believe the best place for the workaround is in the batch files themselves. Using a subroutine (like shown ) for seems to be the only reliable thing to do.