Change:
# *not* use debug assertions and llvm assertions. This is because they take # too long on appveyor and this is tested by rustbuild below. - MSYS_BITS: 32 <del> RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu </del> <ins> RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-ninja </ins> 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_DIR: mingw32 - MSYS_BITS: 64 SCRIPT: python x.py test <del> RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu </del> <ins> RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-ninja </ins> MINGW_URL: https://s3.amazonaws.com/rust-lang-ci MINGW_ARCHIVE: x86_64-4.9.2-release-win32-seh-rt_v4-rev4.7z MINGW_DIR: mingw64

Discussion:
I've previously been classifying these errors under but now I'm thinking that's incorrect, I suspect these are totally separate errors.
The is quite ominous. My preference for an attempt to fix this would be to switch to ninja as it's likely just flat out more reliable than makefiles on MinGW
Oh also we're going to want to switch the MSVC build to Ninja regardless, so we'll have it available anyway eventually on the bots.
I've met it few times with MSYS2 and (almost?) always it was caused by CL RF line endings or too long paths or file names. When compiling Rust from git I found there are files that windows explorer cannot remove since they are too long. Unfortunately I don't have list as I used MSYS2 to clean those files.
Unfortunately it looks like
to fix this
Nope,
You can try changing temp directory if it is possible with rustbuild. Dnia 29 marca 2017 19:01:24 CEST, Alex Crichton <notifications
Just looked it up because I was curious - in theory appveyor uses (i.e. newlines are always checkout out as LF), which is the suggested solution in the SO post. So no help there.
Does not look fixed to me :( My untrained eyes aren't seeing much of a pattern though... 18 total appveyor builds in the last 24 hours (1.0.2792-1.0.2809) 5 marked as cancelled 5 passed 2 failed for other reasons 6 failed for this reason 3 say "No such file", 3 say "Permission denied". form building : from building : from building : from building : from building : from building :
I ran the LLVM build a few dozen times locally and it failed lots of times with 6.2.0 (that we're using). I re-verified and it has yet to fail with 6.3.0. Some next steps: Identify the change between 6.2.0 and 6.3.0 that fixed this problem we're seeing Identify what changed in gdb between 6.2.0 and 6.3.0 that causes our test suite to regress See if we can mix/match 6.2.0 and 6.3.0
Does anyone know where the source code and/or build configuration are for the ?

Best I can find there is 6.1.0 and nothing afterwards...
that's a good question. Guess you will have to ask niXman who releases prebuilt packages:
According to this , the problem is the new gdb. Could you try using the gdb from 6.2.0 and everything else from 6.3.0?
when you install everything from mingw-builds everything is bundled. MSYS2 in turn provides packages but they require recent libraries to work properly, however it is possible to build own package against old libraries but it would have to be self hosted by Rust team.
We could bundle the "known-good" old gdb and copy it or something.
Why don't the rust team just use or patch the MINGW(not MSYS) llvm provided by MSYS2 project? It's absolutely much easier to use and upgrade, right? (They've even got llvm 4.0 ready now...) They use PKGBUILDs to build the packages. It seems there's quite a few patches needed though. (They've also got a PKGBUILD for mingw-w64-rust... and shipping prebuilt rust 1.16)
yes I think that's the best solution here. ah we don't want to rely on the msys packages as well b/c we can't pin versions. They'll change from under our feet which runs the risk of breaking the build which we'd prefer to avoid. this isn't related to LLVM, it's related to the gcc/gdb toolchain versions
This is, unfortunately, still a problem. See
Possibly a false alarm. is targeting the beta branch, which presumably does not have the fix for this failure, in which case it's "normal" for it to fail spuriously. Will leave open for someone to confirm, though.
ah yeah I think we're ok, , the fix, is only on master not on beta