Upgrade pre-built Clang used in MSVC and MacOS builds, move MSVC builds to Server 2022 #124850
Conversation
rustbot
added
A-testsuite
|
I wonder why the build is slower now. Master: Windows 2022: Could you please add the jobs to the |
Done |
|
@bors try |
Upgrade pre-built Clang used in MSVC and MacOS builds, move MSVC builds to Server 2022 Fixes rust-lang#92948 Example working MacOS and Windows builds: <https://github.com/rust-lang/rust/actions/runs/8989360201> Using Server 2022 for AArch64 MSVC is blocked by <llvm/llvm-project#81849>. I'll see if I can work around the issue in a follow up PR.
Looks like a little from git, but the majority was building LLVM. Comparing the x86-64 builds:
The LLVM build slowdown makes sense, given that we wrap Clang in SCCache to speed up the build, but we wouldn't have a cached build using the updated version of Clang. |
|
Yeah, that makes sense. Let's see if sccache helps. |
|
First run is complete, can we try again and see if it picks up the cached build from the last attempt (assuming that |
|
@bors try |
Upgrade pre-built Clang used in MSVC and MacOS builds, move MSVC builds to Server 2022 Fixes rust-lang#92948 Example working MacOS and Windows builds: <https://github.com/rust-lang/rust/actions/runs/8989360201> Using Server 2022 for AArch64 MSVC is blocked by <llvm/llvm-project#81849>. I'll see if I can work around the issue in a follow up PR.
|
☀️ Try build successful - checks-actions |
|
Ok, it's fast again, great. Could you please remove the CI modifications? Otherwise PR looks good to me. |
Done - thanks so much for helping out with this :) |
|
@bors r+ rollup=never |
bors
added
S-waiting-on-bors
|
Thanks for preparing and testing this! Let's see if it works. |
This comment has been minimized.
This comment has been minimized.
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
Ah, interesting, it's Clang 18 that breaks aarch64-msvc, not VS 2022's STL - I guess I'll have to apply the workaround to this PR... |
rustbot
added
the
T-bootstrap
This comment has been minimized.
This comment has been minimized.
|
@Kobzol Workaround for aarch64-msvc has been implemented: please have a look at |
|
@bors r+ |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (a6e87c5): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 673.028s -> 675.734s (0.40%) |
(ci) Update macOS Xcode to 15 This updates the macOS builders to Xcode 15. The aarch64 images will be removing Xcode 14 and 16 very soon (actions/runner-images#10703), so we will need to make the switch to continue operating. The linked issue also documents GitHub's new policy for how they will be updating Xcode in the future. Also worth being aware of is the future plans for x86 runners documented in actions/runner-images#9255 and actions/runner-images#10686, which will impact our future upgrade behaviors. I decided to also update the Xcode in the x86_64 runners, even though they are not being removed. It felt better to me to have all macOS runners on the same (major) version of Xcode. However, note that the x86_64 runners do not have the latest version of 15 (15.4), so I left them at 15.2 (which is currently the default Xcode of the runner). Xcode 15 was previously causing problems (see rust-lang#121058) which seem to be resolved now. `@bjorn3` fixed the `invalid r_symbolnum` issue with cranelift. The issue with clang failing to link seems to be fixed, possibly by the update of the pre-built LLVM from 14 to llvm 15 in rust-lang#124850, or an update in our source version of LLVM. I have run some try builds and at least LLVM seems to build (I did not run any tests). Closes rust-lang#121058
(ci) Update macOS Xcode to 15 This updates the macOS builders to Xcode 15. The aarch64 images will be removing Xcode 14 and 16 very soon (actions/runner-images#10703), so we will need to make the switch to continue operating. The linked issue also documents GitHub's new policy for how they will be updating Xcode in the future. Also worth being aware of is the future plans for x86 runners documented in actions/runner-images#9255 and actions/runner-images#10686, which will impact our future upgrade behaviors. I decided to also update the Xcode in the x86_64 runners, even though they are not being removed. It felt better to me to have all macOS runners on the same (major) version of Xcode. However, note that the x86_64 runners do not have the latest version of 15 (15.4), so I left them at 15.2 (which is currently the default Xcode of the runner). Xcode 15 was previously causing problems (see rust-lang#121058) which seem to be resolved now. `@bjorn3` fixed the `invalid r_symbolnum` issue with cranelift. The issue with clang failing to link seems to be fixed, possibly by the update of the pre-built LLVM from 14 to llvm 15 in rust-lang#124850, or an update in our source version of LLVM. I have run some try builds and at least LLVM seems to build (I did not run any tests). Closes rust-lang#121058
(ci) Update macOS Xcode to 15 This updates the macOS builders to Xcode 15. The aarch64 images will be removing Xcode 14 and 16 very soon (actions/runner-images#10703), so we will need to make the switch to continue operating. The linked issue also documents GitHub's new policy for how they will be updating Xcode in the future. Also worth being aware of is the future plans for x86 runners documented in actions/runner-images#9255 and actions/runner-images#10686, which will impact our future upgrade behaviors. I decided to also update the Xcode in the x86_64 runners, even though they are not being removed. It felt better to me to have all macOS runners on the same (major) version of Xcode. However, note that the x86_64 runners do not have the latest version of 15 (15.4), so I left them at 15.2 (which is currently the default Xcode of the runner). Xcode 15 was previously causing problems (see #121058) which seem to be resolved now. `@bjorn3` fixed the `invalid r_symbolnum` issue with cranelift. The issue with clang failing to link seems to be fixed, possibly by the update of the pre-built LLVM from 14 to llvm 15 in rust-lang/rust#124850, or an update in our source version of LLVM. I have run some try builds and at least LLVM seems to build (I did not run any tests). Closes #121058
(ci) Update macOS Xcode to 15 This updates the macOS builders to Xcode 15. The aarch64 images will be removing Xcode 14 and 16 very soon (actions/runner-images#10703), so we will need to make the switch to continue operating. The linked issue also documents GitHub's new policy for how they will be updating Xcode in the future. Also worth being aware of is the future plans for x86 runners documented in actions/runner-images#9255 and actions/runner-images#10686, which will impact our future upgrade behaviors. I decided to also update the Xcode in the x86_64 runners, even though they are not being removed. It felt better to me to have all macOS runners on the same (major) version of Xcode. However, note that the x86_64 runners do not have the latest version of 15 (15.4), so I left them at 15.2 (which is currently the default Xcode of the runner). Xcode 15 was previously causing problems (see #121058) which seem to be resolved now. `@bjorn3` fixed the `invalid r_symbolnum` issue with cranelift. The issue with clang failing to link seems to be fixed, possibly by the update of the pre-built LLVM from 14 to llvm 15 in rust-lang/rust#124850, or an update in our source version of LLVM. I have run some try builds and at least LLVM seems to build (I did not run any tests). Closes #121058
Fixes #92948
Example working MacOS and Windows builds: https://github.com/rust-lang/rust/actions/runs/8989360201
There is a bug in Clang 18 that causes issues when building for Arm64 in later parts of the build (specifically
libgit2). As a workaround, we will still use the pre-built Clang to build LLVM but will use MSVC for the rest of the Arm64 build.