Update to Xcode 26.2 by madsmtm · Pull Request #152013 · rust-lang/rust

madsmtm · 2026-02-02T22:14:43Z

Update our CI to run with Xcode 26.

This means that:

LLVM will be built with a newer Clang version (before Apple Clang 15, now Apple Clang 17).
Our binaries (e.g. rustc and libstd*.dylib) will have their SDK version raised (before macOS 14.5, now 26.2).
Our binaries will be built with a newer linker (before 1053.12, now 1230.1).

The last two points can be observed with:

$ vtool -show-build ./build/host/stage1/bin/rustc
Load command 10
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform MACOS
    minos 11.0
      sdk 26.2
   ntools 1
     tool LD
  version 1230.1
$ vtool -show-build ./build/host/stage1/lib/rustlib/aarch64-apple-darwin/lib/libstd*.dylib
Load command 9
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform MACOS
    minos 11.0
      sdk 26.2
   ntools 1
     tool LD
  version 1230.1

This shouldn't have much of an effect, but things like dyld is known to inspect the SDK version, so it might expose some latent bugs (I really don't expect it to though).

This also updates the macOS runners to run on macOS 15 (the macOS 14 runners only have up to Xcode 16.2 available). That is desirable anyhow, as the macOS 14 runners will be deprecated in July. This is probably also required for #147192.

r? shepmaster

madsmtm · 2026-02-02T22:27:26Z

I suspect this will run into issues with some badly written tests, will do a CI run once it starts working again.

madsmtm · 2026-02-03T00:00:04Z

@bors try jobs=apple

Update to Xcode 26.2 try-job: *apple*

rust-bors · 2026-02-03T03:15:03Z

💔 Test for 16cbdc0 failed: CI. Failed job:

try - dist-apple-various (web logs, enhanced plaintext logs)

madsmtm · 2026-02-03T10:20:07Z

I think we might need to use the Xcode-provided Clang on dist-apple-various as well to be able to build properly with the new headers. Let's try that:

@bors try jobs=apple

Update to Xcode 26.2 try-job: *apple*

rust-bors · 2026-02-03T16:23:21Z

💥 Test timed out after 21600s

madsmtm · 2026-02-03T19:16:36Z

Hmm. I'd expect the first build with this to take longer because it busts basically the entire build cache, but I wouldn't have expected it to take that long.

Maybe it's due to the recent CI outage that GitHub Actions had, which might make jobs slower while they're catching up? I'll wait a few more hours to a day, and then retry the build.

madsmtm · 2026-02-05T13:19:00Z

@bors try jobs=apple

Update to Xcode 26.2 try-job: *apple*

rust-bors · 2026-02-05T18:08:47Z

☀️ Try build successful (CI)
Build commit: 68c715b (68c715b83df224fe567367e20296073d0f938d59, parent: 0a13b4361264236cb40afebea97973e6dc366de3)

madsmtm · 2026-02-05T23:17:58Z

Yay, that worked. Need to land #152192 first.
@rustbot blocked

…shepmaster Always use Xcode-provided Clang in macOS CI Most of our macOS CI runners use the Xcode-provided Clang. `dist-apple-various` still downloads Clang from LLVM's prebuilt sources, which is a bit problematic, because we're still using the Xcode-provided _headers_. As a concrete example, using Xcode's Clang is required by rust-lang#152013, as otherwise updating to Xcode 26 headers fails with an obscure `fatal error: 'net/route.h' file not found`, see [this build log](rust-lang#152013 (comment)). I suspect this is because building the new headers isn't officially supported with the older LLVM/Clang 15. This PR removes that functionality, so that we instead always build with the Xcode-provided Clang. This is effectively the same as setting `USE_XCODE_CLANG=1` on `dist-apple-various` as well, but I thought I'd clean things up while I'm at it. I didn't find the reason why we did this in first place, maybe because the Xcode Clang at the time was too out of date to build LLVM? It doesn't seem to be a problem anymore though. r? t-infra

Rollup merge of #152192 - madsmtm:remove-use-xcode-clang, r=shepmaster Always use Xcode-provided Clang in macOS CI Most of our macOS CI runners use the Xcode-provided Clang. `dist-apple-various` still downloads Clang from LLVM's prebuilt sources, which is a bit problematic, because we're still using the Xcode-provided _headers_. As a concrete example, using Xcode's Clang is required by #152013, as otherwise updating to Xcode 26 headers fails with an obscure `fatal error: 'net/route.h' file not found`, see [this build log](#152013 (comment)). I suspect this is because building the new headers isn't officially supported with the older LLVM/Clang 15. This PR removes that functionality, so that we instead always build with the Xcode-provided Clang. This is effectively the same as setting `USE_XCODE_CLANG=1` on `dist-apple-various` as well, but I thought I'd clean things up while I'm at it. I didn't find the reason why we did this in first place, maybe because the Xcode Clang at the time was too out of date to build LLVM? It doesn't seem to be a problem anymore though. r? t-infra

This also updates the macOS runners to run on macOS 15 (the macOS 14 runners only have up to Xcode 16.2 available).

madsmtm · 2026-02-06T19:22:14Z

#152192 landed, so:
@rustbot ready

Pretty sure that this will succeed this time too, but just to be sure.
@bors try jobs=apple

Update to Xcode 26.2 try-job: *apple*

rust-bors · 2026-02-07T01:23:03Z

💥 Test timed out after 21600s

madsmtm · 2026-02-07T04:37:55Z

Seems like the second time might have access to more cached data:
@bors try jobs=apple

Update to Xcode 26.2 try-job: *apple*

rust-bors · 2026-02-07T10:43:01Z

💥 Test timed out after 21600s

madsmtm · 2026-02-08T06:50:11Z

Hmm. I'll try one more time, it did work before:
@bors try jobs=apple

(Note that I don't consider it an option to not do this upgrade, so if CI times have actually gotten worse because of this, we'll have to split up the work into separate steps).

Update to Xcode 26.2 try-job: *apple*

rust-bors · 2026-02-08T10:13:23Z

☀️ Try build successful (CI)
Build commit: 5f9b8c6 (5f9b8c62721c2963e903597d36bfd5eb9df99887, parent: 08a4ce529f4ea17ad1c0fa2e39ca1f5e7cd047b6)

madsmtm · 2026-02-08T12:14:35Z

Seemed to complete within reasonable timeframes, so was probably just some caching weirdness.

@rustbot ready

madsmtm · 2026-02-08T12:19:11Z

This is probably compile-time performance-sensitive, since LLVM will be built with a newer Clang version (as I understand it, LLVM is only built once, unlike rustc's stage 1 and 2 compilers?)

Should still be safe to rollup though, as macOS performance isn't tested by rustc-perf.
@bors rollup=always

madsmtm added O-macos Operating system: macOS T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. A-CI Area: Our Github Actions CI O-apple Operating system: Apple / Darwin (macOS, iOS, tvOS, visionOS, watchOS) labels Feb 2, 2026

rustbot assigned shepmaster Feb 2, 2026

rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 2, 2026

madsmtm mentioned this pull request Feb 2, 2026

LLDB testing should be disabled #151966

Closed

madsmtm changed the title ~~ci: Update to Xcode 26.2~~ Update to Xcode 26.2 Feb 2, 2026