appveyor: Upgrade MinGW toolchains we use

In debugging #40546 I was able to reproduce locally finally using
the literal toolchain that the bots were using. I reproduced the error maybe 4
in 10 builds. I also have the 6.3.0 toolchain installed through `pacman` which
has yet to have a failed build.

When attempting to reproduce the bug with the toolchain that this commit
switches to I was unable to reproduce anything after a few builds. I have no
idea what the original problem was, but I'm hoping that it was just some random
bug fixed somewhere along the way.

I don't currently know of a technical reason to stick to the 4.9.2 toolchains we
were previously using. Historcal 5.3.* toolchains would cause llvm to segfault
(maybe a miscompile?) but this seems to have been fixed recently. To me if it
passes CI then I think we're good.

Closes #40546

Author: alexcrichton

appveyor.yml

@@ -45,14 +45,14 @@ environment:
   - MSYS_BITS: 32
     RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-ninja
     SCRIPT: python x.py test
-    MINGW_URL: https://s3.amazonaws.com/rust-lang-ci
-    MINGW_ARCHIVE: i686-4.9.2-release-win32-dwarf-rt_v4-rev4.7z
+    MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror
+    MINGW_ARCHIVE: i686-6.3.0-release-win32-dwarf-rt_v5-rev1.7z
     MINGW_DIR: mingw32
   - MSYS_BITS: 64
     SCRIPT: python x.py test
     RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-ninja
-    MINGW_URL: https://s3.amazonaws.com/rust-lang-ci
-    MINGW_ARCHIVE: x86_64-4.9.2-release-win32-seh-rt_v4-rev4.7z
+    MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror
+    MINGW_ARCHIVE: x86_64-6.3.0-release-win32-seh-rt_v5-rev1.7z
     MINGW_DIR: mingw64
 
   # 32/64 bit MSVC and GNU deployment
@@ -70,15 +70,15 @@ environment:
   - MSYS_BITS: 32
     RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-extended --enable-ninja
     SCRIPT: python x.py dist
-    MINGW_URL: https://s3.amazonaws.com/rust-lang-ci
-    MINGW_ARCHIVE: i686-4.9.2-release-win32-dwarf-rt_v4-rev4.7z
+    MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror
+    MINGW_ARCHIVE: i686-6.3.0-release-win32-dwarf-rt_v5-rev1.7z
     MINGW_DIR: mingw32
     DEPLOY: 1
   - MSYS_BITS: 64
     SCRIPT: python x.py dist
     RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-extended --enable-ninja
-    MINGW_URL: https://s3.amazonaws.com/rust-lang-ci
-    MINGW_ARCHIVE: x86_64-4.9.2-release-win32-seh-rt_v4-rev4.7z
+    MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror
+    MINGW_ARCHIVE: x86_64-6.3.0-release-win32-seh-rt_v5-rev1.7z
     MINGW_DIR: mingw64
     DEPLOY: 1
 

src/test/run-pass/issue-16671.rs

@@ -8,26 +8,13 @@
 // option. This file may not be copied, modified, or distributed
 // except according to those terms.
 
-// DON'T REENABLE THIS UNLESS YOU'VE ACTUALLY FIXED THE UNDERLYING ISSUE
-// ignore-android seems to block forever
+#![deny(warnings)]
 
-// ignore-emscripten no threads support
+fn foo<F: FnOnce()>(_f: F) { }
 
-#![forbid(warnings)]
-
-// Pretty printing tests complain about `use std::predule::*`
-#![allow(unused_imports)]
-
-// A var moved into a proc, that has a mutable loan path should
-// not trigger a misleading unused_mut warning.
-
-use std::io::prelude::*;
-use std::thread;
-
-pub fn main() {
-    let mut stdin = std::io::stdin();
-    thread::spawn(move|| {
-        let mut v = Vec::new();
-        let _ = stdin.read_to_end(&mut v);
-    }).join().ok().unwrap();
+fn main() {
+    let mut var = Vec::new();;
+    foo(move|| {
+        var.push(1);
+    });
 }

src/tools/compiletest/src/procsrv.rs

@@ -57,9 +57,26 @@ pub fn run(lib_path: &str,
 
     let mut cmd = Command::new(prog);
     cmd.args(args)
-        .stdin(Stdio::piped())
         .stdout(Stdio::piped())
         .stderr(Stdio::piped());
+
+    // Why oh why do we sometimes make a pipe and sometimes inherit the stdin
+    // stream, well that's an excellent question! In theory it should suffice to
+    // always create a pipe here and be done with it. Unfortunately though
+    // there's apparently something odd with the gdb that comes with gcc 6.3.0
+    // on MinGW. Tracked at rust-lang/rust#40184 when stdin is piped here
+    // (unconditionally) then all gdb tests will fail on MinGW when using gcc
+    // 6.3.0. WHen using an inherited stdin though they happen to all work!
+    //
+    // As to why this fixes the issue, well, I have no idea. If you can remove
+    // this branch and unconditionally use `piped` and it gets past @bors please
+    // feel free to send a PR!
+    if input.is_some() || !cfg!(windows) {
+        cmd.stdin(Stdio::piped());
+    } else {
+        cmd.stdin(Stdio::inherit());
+    }
+
     add_target_env(&mut cmd, lib_path, aux_path);
     for (key, val) in env {
         cmd.env(&key, &val);