Always use Xcode-provided Clang in macOS CI#152192
Open
madsmtm wants to merge 3 commits intorust-lang:mainfrom
Open
Always use Xcode-provided Clang in macOS CI#152192madsmtm wants to merge 3 commits intorust-lang:mainfrom
madsmtm wants to merge 3 commits intorust-lang:mainfrom
Conversation
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
added
O-macos
rustbot
added
A-testsuite
madsmtm
added
the
O-apple
Contributor
Author
|
@bors try jobs=apple |
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Feb 5, 2026
Always use Xcode-provided Clang in macOS CI try-job: *apple*
rust-bors
bot
added
S-waiting-on-author
Contributor
|
💥 Test timed out after |
Contributor
Author
|
@bors retry |
Contributor
|
❗ You can only retry pull requests that are approved and have a previously failed auto build. |
Contributor
Author
|
Right, I wanted you to retry the try, not retry the merge ;) @bors try jobs=apple |
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Feb 6, 2026
Always use Xcode-provided Clang in macOS CI try-job: *apple*
Contributor
Contributor
Author
|
@rustbot ready |
rustbot
added
S-waiting-on-review
Member
|
I'm happy to bring more things into alignment! @bors r+ rollup |
Contributor
rust-bors
bot
added
the
S-waiting-on-bors
rust-bors
bot
removed
the
S-waiting-on-review
Member
For my own notes: we were setting
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. |
TaKO8Ki
added a commit
to TaKO8Ki/rust
that referenced
this pull request
Feb 6, 2026
…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
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Feb 6, 2026
…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
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Feb 6, 2026
…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
rust-bors bot
pushed a commit
that referenced
this pull request
Feb 6, 2026
…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)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Most of our macOS CI runners use the Xcode-provided Clang.
dist-apple-variousstill 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=1ondist-apple-variousas 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