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: While working on I've discovered that on nightly the std::Command::new() for a windows 10 batch script "" results in underlying node-js process to not find required resource paths. I tried this code: I expected to see this happen: This works on all channels for my linux and windows 7 boxes (did not test other than msvc here) as well as stable and beta for windows 10 box (and appveyor) Instead, this happened only on windows 10 (and appveyor) msvc nightly: Please note that the panic is explicitly triggered in to make appveyor report the error. The sets paths for node-js via environmental variables and these seem not to be forwarded properly. Sorry for mostly useless description as I have no experience with npm/node and no access to the actual win10 box on which the problem was reproduced (I was only able to locate this problem via appveor logs). But the problem exists at least since (sorry no verbose output here. I have no access to that win10 box anymore) Link to appveyor showing the problem:
So you're saying the combination of Rust nightly and either appveyor or Windows 10 is causing the npm stuff to fail? Also, the actual error that is occurring here:
What I was able to gather sofar is that env variables in the cmd script might not be forwarded correctly to the nodejs subprocess.
what makes you think this is a rustc bug? It's looking like the process was spawned correctly and output was captured, which makes me think that this may be a local configuration issue?
I am not positive that it is a rustc bug. But identical setup works on windows7 (stable/beta/nightly) as well as the exact same setup works for windows 10 stable/beta and fails on nightly suggests that this might be a regression in stdlib. I am assuming that while process start and output capture works, there might be problem with how the env variables are passed to the child process. I'm no expert on windows nor nodejs (I just happened to help with triage on ) I am assuming that very specific contents of trigger this behavior. I might try to get a hold of win10 box again and try to get the reproduction path down to a manageable minimum.
After some investigating it turns out this is an interesting Windows feature/quirk/bug in how is handled.