Change:
GitHub is starting a migration of to : Migration starts now, and should finish by March 6. It is not clear if that timetable includes the runners. Based on the fact that the runners have not yet migrated to 20.04, which was "completed" in 2021-03-18 (and it is now 2022-01-15), the timing for the images might be much slower. UPDATE from GitHub: Our first goal is to GA Windows 2022 this quarter and then we will start the process of getting the XL pools ready. It may be possible to lock to an older version with (as it appears those version-specific qualifiers work with ubuntu), but I have not tested that. I have started testing some builds in 2022 and they are not going well, I'll try to document some issues here. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Issue: dos2unix does not work The  script fails with the error: I haven't investigated much, but I suspect it might be a conflict with one of our manually downloaded msys/mingw things. also contains some context. As a side note: The install-mingw step installs and updates a bunch of packages, which the 2019 images do not (all the packages are already installed and up-to-date).
Issue: LNK1318 EDIT: This was likely just a full partition error. While building compiletest, it failed to link with this error: These link errors tend to be very difficult to diagnose (like ). I wonder if this may be a consequence of using a non-xl runner which only has 8GB ram (compared to ~32GB of xl)? However, it was able to link rustc which is much larger than compiletest and its proc-macros.
Issue: errors in run-make-fulldeps Many of the run-make-fulldeps tests are failing. Many are probably related to the same underlying problem of handling gnu vs windows paths. x8664-pc-windows-gnu and x8664-pc-windows-msvc fail with about 125 errors, roughly of this form:
It probably needs an update but I'll look at it when I get home. Any recommendations?
Unfortunately I don't know why it is failing. We install a custom mingw and msys2 ( and ), which might be interfering with the system-provided binaries. Or it could be something else, I haven't investigated.
I'd like to have a go at getting this working claim
is there something that I need to do to get access to Server 2022 build agents? I tried modifying the PR build, but it seems to be stuck waiting for agents:
First blocking issue: CI currently installs Clang14 to build LLVM: the STL in VS 2022 requires Clang 16+: 've raised this on Zulip with wg-llvm: <https://rust-
Pinged t-infra for XL Server 2022 images: https://rust-
Draft PR: I'm waiting on the intra team to help out with two things (would appreciate some help to expidite these): There also one test that was failing which I've submitted a PR to fix: x8664-mingw dist-i686-mingw dist-x8664-mingw x8664-msvc i686-msvc x8664-msvc-ext dist-i686-msvc dist-x8664-msvc-alt dist-x8664-msvc - Keeps timing out on the standard build machines, but I don't foresee any other issues. dist-aarch64-msvc - Requires an which is in 19, backporting is not possible as it would be an ABI break.
This was only partially fixed.

Discussion:
// FIXME: the guard against msvc shouldn't need to be here if target.is_msvc() { if let Some(ref cl) = builder.config.llvm_clang_cl { <del> self.command.env("CC", cl).env("CXX", cl); </del> <ins> // FIXME: There is a bug in Clang 18 when building for ARM64: // https://github.com/llvm/llvm-project/pull/81849. This is // fixed in LLVM 19, but can't be backported. if !target.starts_with("aarch64") && !target.starts_with("arm64ec") { self.command.env("CC", cl).env("CXX", cl); } </ins> } } else { let ccache = builder.config.ccache.as_ref();

source shared.sh <ins> # Try to keep the LLVM version here in sync with src/ci/scripts/install-clang.sh </ins> LLVM=llvmorg-18.1.0 mkdir llvm-project

os: windows-2022-16core-64gb <<: *base-job <del> - &job-windows-2019-8c os: windows-2019-8core-32gb <<: *base-job - &job-windows-2019-16c os: windows-2019-16core-64gb <<: *base-job </del> - &job-aarch64-linux os: [ self-hosted, ARM64, linux ]

env: RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc --enable-profiler SCRIPT: make ci-msvc <del> <<: *job-windows-2019-8c </del> <ins> <<: *job-windows-8c </ins> - image: i686-msvc env: RUST_CONFIGURE_ARGS: --build=i686-pc-windows-msvc SCRIPT: make ci-msvc <del> <<: *job-windows-2019-8c </del> <ins> <<: *job-windows-8c </ins> - image: x86_64-msvc-ext env:

HOST_TARGET: x86_64-pc-windows-msvc RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc --enable-lld --save-toolstates=/tmp/toolstate/toolstates.json DEPLOY_TOOLSTATES_JSON: toolstates-windows.json <del> <<: *job-windows-2019-8c </del> <ins> <<: *job-windows-8c </ins> # 32/64-bit MinGW builds. #

--set rust.codegen-units=1 SCRIPT: python x.py build --set rust.debug=true opt-dist && PGO_HOST=x86_64-pc-windows-msvc ./build/x86_64-pc-windows-msvc/stage0-tools-bin/opt-dist windows-ci -- python x.py dist bootstrap --include-default-paths DIST_REQUIRE_ALL_TOOLS: 1 <del> <<: *job-windows-2019-8c </del> <ins> <<: *job-windows-8c </ins> - image: dist-i686-msvc env:

--enable-profiler SCRIPT: python x.py dist bootstrap --include-default-paths DIST_REQUIRE_ALL_TOOLS: 1 <del> <<: *job-windows-2019-8c </del> <ins> <<: *job-windows-8c </ins> - image: dist-aarch64-msvc env:

--enable-profiler SCRIPT: python x.py dist bootstrap --include-default-paths DIST_REQUIRE_ALL_TOOLS: 1 <del> <<: *job-windows-2019-8c </del> <ins> <<: *job-windows-8c </ins> - image: dist-i686-mingw env:

env: RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc --enable-extended --enable-profiler SCRIPT: python x.py dist bootstrap --include-default-paths <del> <<: *job-windows-2019-8c </del> <ins> <<: *job-windows-8c </ins>

source "$(cd "$(dirname "$0")" && pwd)/../shared.sh" # Update both macOS's and Windows's tarballs when bumping the version here. <del> LLVM_VERSION="14.0.5" </del> <ins> # Try to keep this in sync with src/ci/docker/host-x86_64/dist-x86_64-linux/build-clang.sh LLVM_VERSION="18.1.4" </ins> if isMacOS; then <ins> # FIXME: This is the latest pre-built version of LLVM that's available for # x86_64 MacOS. We may want to consider bulding our own LLVM binaries # instead, or set `USE_XCODE_CLANG` like AArch64 does. LLVM_VERSION="15.0.7" </ins> # If the job selects a specific Xcode version, use that instead of # downloading our own version. if [[ ${USE_XCODE_CLANG-0} -eq 1 ]]; then bindir="$(xcode-select --print-path)/Toolchains/XcodeDefault.xctoolchain/usr/bin" else <del> file="${MIRRORS_BASE}/clang%2Bllvm-${LLVM_VERSION}-x86_64-apple-darwin.tar.xz" retry curl -f "${file}" -o "clang+llvm-${LLVM_VERSION}-x86_64-apple-darwin.tar.xz" tar xJf "clang+llvm-${LLVM_VERSION}-x86_64-apple-darwin.tar.xz" bindir="$(pwd)/clang+llvm-${LLVM_VERSION}-x86_64-apple-darwin/bin" </del> <ins> file="${MIRRORS_BASE}/clang%2Bllvm-${LLVM_VERSION}-x86_64-apple-darwin21.0.tar.xz" retry curl -f "${file}" -o "clang+llvm-${LLVM_VERSION}-x86_64-apple-darwin21.0.tar.xz" tar xJf "clang+llvm-${LLVM_VERSION}-x86_64-apple-darwin21.0.tar.xz" bindir="$(pwd)/clang+llvm-${LLVM_VERSION}-x86_64-apple-darwin21.0/bin" </ins> fi ciCommandSetEnv CC "${bindir}/clang"