compile-fail tests sometimes considered sucessfully compiled by the test harness

[ghost]

Occasionally a PR will fail the bors integration due to a compile-fail test compiling successfully... except not, as evidenced here: http://buildbot.rust-lang.org/builders/auto-win-32-opt/builds/1928/steps/test/logs/stdio

---- [compile-fail] compile-fail/issue-17718-static-sync.rs stdout ----

    error: compile-fail test compiled successfully!
    status: exit code: 0
    command: PATH="i686-pc-windows-gnu/stage2/bin;.;C:\program files (x86)\mingw-w64\i686-4.8.1-win32-dwarf-rt_v3-rev2\mingw32\bin;C:\msys64\usr\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\msys64\usr\bin;C:\python27;C:\python27\scripts;C:\program files (x86)\inno setup 5;C:\program files (x86)\CMake\bin;i686-pc-windows-gnu\stage2\bin\rustlib\i686-pc-windows-gnu\lib" i686-pc-windows-gnu\stage2\bin\rustc.exe C:\bot\slave\auto-win-32-opt\build\src\test\compile-fail\issue-17718-static-sync.rs -L i686-pc-windows-gnu\test\compile-fail --target=i686-pc-windows-gnu -L i686-pc-windows-gnu\test\compile-fail\issue-17718-static-sync.stage2-i686-pc-windows-gnulibaux -C prefer-dynamic -o i686-pc-windows-gnu\test\compile-fail\issue-17718-static-sync.stage2-i686-pc-windows-gnu.exe --cfg rtopt --cfg debug -O -L i686-pc-windows-gnu/rt
    stdout:
    ------------------------------------------

    ------------------------------------------
    stderr:
    ------------------------------------------
    C:\bot\slave\auto-win-32-opt\build\src\test\compile-fail\issue-17718-static-sync.rs:16:19: 16:49 error: shared static items must have a type which implements Sync
    C:\bot\slave\auto-win-32-opt\build\src\test\compile-fail\issue-17718-static-sync.rs:16 static BAR: Foo = Foo { marker: marker::NoSync };
                                                                                                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    error: aborting due to previous error

The compiler's output suggests that it's the test harness that somehow misreads the exit code. This might be a library issue in std::io::process::Command.

[alexcrichton]

This has been happening for quite some time as well. I've only ever seen this happen on Windows, never on Unix. (a few more data points)

[alexcrichton]

I do somewhat suspect an issue with Command...

[alexcrichton]

I haven't seen this in quite some time, and I touched up a few suspicious areas in the new process module when it went through the most recent I/O reform, so I'm going to tentatively close this in hopes that it's actually fixed!