Always use Xcode-provided Clang in macOS CI by madsmtm · Pull Request #152192 · rust-lang/rust

madsmtm · 2026-02-05T23:16:27Z

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. 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

Instead, always use the Xcode-provided Clang to build LLVM.

Bootstrap no longer infers the archiver as `clang-ar`, so we don't need to set this explicitly.

Instead of manually setting up CC/CXX environment variables, use the default configuration that Xcode gives us.

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

@bors try jobs=apple

Always use Xcode-provided Clang in macOS CI try-job: *apple*

rust-bors · 2026-02-06T05:23:03Z

💥 Test timed out after 21600s

madsmtm · 2026-02-06T06:49:20Z

@bors retry

rust-bors · 2026-02-06T06:49:24Z

❗ You can only retry pull requests that are approved and have a previously failed auto build.

madsmtm · 2026-02-06T06:50:16Z

Right, I wanted you to retry the try, not retry the merge ;)

@bors try jobs=apple

Always use Xcode-provided Clang in macOS CI try-job: *apple*

rust-bors · 2026-02-06T10:02:00Z

☀️ Try build successful (CI)
Build commit: c4619b7 (c4619b7af1e6bb62315400fb998598d9d3012bb0, parent: a3ceeeb26c31eb15ace604890cef17d75a735ed2)

madsmtm · 2026-02-06T11:00:16Z

@rustbot ready

shepmaster · 2026-02-06T13:30:13Z

I'm happy to bring more things into alignment!

@bors r+ rollup

rust-bors · 2026-02-06T13:30:16Z

📌 Commit 3882573 has been approved by shepmaster

It is now in the queue for this repository.

shepmaster · 2026-02-06T13:35:26Z

we instead always build with the Xcode-provided Clang. This is effectively the same as setting USE_XCODE_CLANG=1 on dist-apple-various

For my own notes: we were setting USE_XCODE_CLANG=1 on all the big-name jobs (e.g. aarch64 and x86_64 dist builds), so there's not as much change as it looks at first.

I didn't find the reason why we did this in first place

I think that was me, and if I recall, it was because there was no upstream clang that could do the cross-compilation to aarch64 at the time, only the special version that Apple shipped on the DTKs.

…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

…uwer Rollup of 6 pull requests Successful merges: - #151590 (cmse: don't use `BackendRepr` when checking return type) - #151945 (feat: Add `NonZero::<T>::from_str_radix`) - #152000 (Fix ICE in normalizing inherent associated consts with `#[type_const]`) - #152192 (Always use Xcode-provided Clang in macOS CI) - #152196 (bootstrap: Remove `ShouldRun::paths`) - #152222 (Re-add TaKO8Ki to triagebot review queue)

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

madsmtm added 3 commits February 5, 2026 23:55

Remove USE_XCODE_CLANG
0bbc2f2
Instead, always use the Xcode-provided Clang to build LLVM.

Remove AR=ar env var
19a7bd9
Bootstrap no longer infers the archiver as `clang-ar`, so we don't need to set this explicitly.

Always use default Clang on macOS
3882573
Instead of manually setting up CC/CXX environment variables, use the default configuration that Xcode gives us.

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 labels Feb 5, 2026

rustbot assigned shepmaster Feb 5, 2026

rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 5, 2026

madsmtm added the O-apple Operating system: Apple / Darwin (macOS, iOS, tvOS, visionOS, watchOS) label Feb 5, 2026

madsmtm mentioned this pull request Feb 5, 2026
Bump tvOS, visionOS and watchOS Aarch64 targets to tier 2 #152021
Merged

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Feb 5, 2026
Auto merge of#152192- madsmtm:remove-use-xcode-clang, r=<try>
789b086
Always use Xcode-provided Clang in macOS CI try-job: *apple*

madsmtm mentioned this pull request Feb 5, 2026
Update to Xcode 26.2 #152013
Merged

rust-borsBot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 6, 2026

This comment has been minimized.
Sign in to view

rust-borsBot pushed a commit that referenced this pull request Feb 6, 2026
Auto merge of#152192- madsmtm:remove-use-xcode-clang, r=<try>
c4619b7
Always use Xcode-provided Clang in macOS CI try-job: *apple*

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 6, 2026

rust-borsBot added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Feb 6, 2026

rust-borsBot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 6, 2026

TaKO8Ki mentioned this pull request Feb 6, 2026
Rollup of 3 pull requests #152223
Closed

This was referenced Feb 6, 2026
Rollup of 5 pull requests #152224
Closed
Rollup of 6 pull requests #152230
Merged

rust-borsBot merged commit 5372fab into rust-lang:mainFeb 6, 2026
12 checks passed

rustbot added this to the 1.95.0 milestone Feb 6, 2026

madsmtm deleted the remove-use-xcode-clang branch February 6, 2026 19:15

github-actionsBot mentioned this pull request Feb 10, 2026
Toolchain upgrade to nightly-2026-02-09 flux-rs/flux#1345
Closed

Navigation Menu

Uh oh!

Uh oh!

Always use Xcode-provided Clang in macOS CI - #152192

Always use Xcode-provided Clang in macOS CI#152192
rust-bors[bot] merged 3 commits into
rust-lang:mainfrom
madsmtm:remove-use-xcode-clang

madsmtm commented Feb 5, 2026

Uh oh!

madsmtm commented Feb 5, 2026

Uh oh!

This comment has been minimized.

rust-borsBot commented Feb 6, 2026

Uh oh!

madsmtm commented Feb 6, 2026

Uh oh!

rust-borsBot commented Feb 6, 2026

Uh oh!

madsmtm commented Feb 6, 2026

Uh oh!

This comment has been minimized.

rust-borsBot commented Feb 6, 2026

Uh oh!

madsmtm commented Feb 6, 2026

Uh oh!

shepmaster commented Feb 6, 2026

Uh oh!

rust-borsBot commented Feb 6, 2026

Uh oh!

shepmaster commented Feb 6, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

madsmtm commented Feb 5, 2026

Uh oh!

madsmtm commented Feb 5, 2026

Uh oh!

This comment has been minimized.

rust-borsBot commented Feb 6, 2026

Uh oh!

madsmtm commented Feb 6, 2026

Uh oh!

rust-borsBot commented Feb 6, 2026

Uh oh!

madsmtm commented Feb 6, 2026

Uh oh!

This comment has been minimized.

rust-borsBot commented Feb 6, 2026

Uh oh!

madsmtm commented Feb 6, 2026

Uh oh!

shepmaster commented Feb 6, 2026

Uh oh!

rust-borsBot commented Feb 6, 2026

Uh oh!

shepmaster commented Feb 6, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants