Code change:
# 32/64-bit MinGW builds. # <del> # The MinGW builds unfortunately have to both download a custom toolchain and # avoid the one installed by AppVeyor by default. Interestingly, though, for # different reasons! </del> <ins> # We are using MinGW with posix threads since LLVM does not compile with # the win32 threads version due to missing support for C++'s std::thread. </ins> # <del> # For 32-bit the installed gcc toolchain on AppVeyor uses the pthread # threading model. This is unfortunately not what we want, and if we compile # with it then there's lots of link errors in the standard library (undefined # references to pthread symbols). # # For 64-bit the installed gcc toolchain is currently 5.3.0 which # unfortunately segfaults on Windows with --enable-llvm-assertions (segfaults # in LLVM). See rust-lang/rust#28445 for more information, but to work around # this we go back in time to 4.9.2 specifically. </del> <ins> # Instead of relying on the MinGW version installed on appveryor we download # and install one ourselves so we won't be surprised by changes to appveyor's # build image. </ins> # # Finally, note that the downloads below are all in the `rust-lang-ci` S3 # bucket, but they cleraly didn't originate there! The downloads originally # came from the mingw-w64 SourceForge download site. Unfortunately # SourceForge is notoriously flaky, so we mirror it on our own infrastructure. <del> # # And as a final point of note, the 32-bit MinGW build using the makefiles do # *not* use debug assertions and llvm assertions. This is because they take # too long on appveyor and this is tested by rustbuild below. </del> - 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/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> 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/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 # 32/64 bit MSVC and GNU deployment

Related discussion:
text: Awesome, thanks in advance!
BTW the PR reference for "llvm::AttrBuilder changed API" is wrong, it points at this issue instead of
Does anyone have ETA? I'd like to know when I can use AVR. :)
You should follow along at avr-rust/rust for the AVR-specific issues. Upgrading to LLVM 4 will not magically yield AVR support.
Ok, thank you!
I've created for the API change.
I've also created for another debug info API change.
After putting all of those patches on top of master, was successfully built. I got several undefined references, most likely due to my local LLVM setup.
I think the next step after all those patches land is to allow LLVM 4.0 in the configure/rustbuild scripts and then actually update the submodule.
We'll also need to fix that AAPCS bug first, I just noticed it
Don't forget : I think that means that the Rust fork of LLVM is following the Emscripten fork of LLVM, thus Emscripten needs to upgrade to LLVM 4.0 / master before Rust can.
And I'm hoping to supersede it with
I just ran into which changed the alignment from u64 to u32. Will think about a proper fix later, unless someone beats me to it (but should merge first to avoid further conflicts).
And it says So, that will be "exciting".
Is there much left blocking an upgrade?
This: Has to be done too but I don't know if it's currently being worked on. Any info on that ^?
No nobody is actively working on an emscripten upgrade. Since even when that is done it will probably take a lot of work to land an LLVM upgrade, there's probably more we can do to prepare. Once we decide we want to do it, somebody can prepare a patch to throw at the bots. It seems likely stuff will not work and it will be a slog to fix it all, which will give us time. We don't need emcc to generate wasm stds, just a fairly small patch on our LLVM branch that will hopefully port without much difficulty. So if somebody feels motivated, it's not too soon to start going after it. As to the emscripten upgrade, we should at least let know that we're starting to think seriously about doing the upgrade, and need emscripten to upgrade LLVM too.