Funny Rust compiler behavior on Windows

21

I'm thinking about it like this:

  • If setting the -o flag changes the output file in any substantial way (i.e. changes anything other than metadata), then this is a critical bug.
  • If, without the -o flag, rustc cannot produce executable on Windows, this is a critical bug.
  • Therefore, if with -o flag rustc cannot produce executable on Windows, there's at least one critical bug (maybe two).
  • In which case, someone would have already dropped you a link to GitHub with the description of this bug.
  • The latter hadn't happened, therefore, rustc must be able to produce executable on Windows with -o flag.

Does this sound reasonable, or do you see any error in this? This is not a proof, strictly speaking, but the proof, as had been said already, can be found by simply trying (I can't do this myself only because on my Windows system there's no Rust installed).

22

No need to be so dramatic. You could just google it if you didn't believe me:

> cargo init .
> rustc -o foo src/main.rs
> Invoke-ExtensionLess foo
Hello, world!

It's annoying in shells because all the magic logic of shells to use an associated file type based on the extension is working against you, but if you are using raw APIs it's not too bad either, you just need to include enough of a path to disable the PATH logic which kicks in the PATHEXT logic too:

fn main() {
    std::process::Command::new(r".\foo").spawn().unwrap();
}

> cargo run --example run_foo
   Compiling can-i-have-that-in-bananas v0.1.0 (D:\scratch\can-i-have-that-in-bananas)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.31s
     Running `target\debug\examples\run_foo.exe`
Hello, world!

Edit: after a bit more testing found you don't need a full path, just enough to disable PATH logic.