-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Demote x86_64-apple-darwin
from Tier 1 to Tier 2 with host tools
#3841
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Demote x86_64-apple-darwin
from Tier 1 to Tier 2 with host tools
#3841
Conversation
84fcc97
to
242cfad
Compare
Starting FCP already, we don't have many options here. |
Team member @Noratrieb has proposed to merge this. The next step is review by the rest of the tagged team members:
Concerns:
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
|
||
The first release after this RFC is merged will be the last one with Tier 1 support for the `x86_64-apple-darwin` target. | ||
The release after that will demote the target to Tier 2 with host tools, | ||
which means it will not be tested by CI. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, we do run some tests for non-tier-1-targets, e.g. some i586 targets. We could probably do the same for x86_64-apple-darwin? IOW, the consequence of this RFC is that we stop promising that we run all the tests, and we'll drop what is impractical, but we don't have to drop everything immediately. We could, for instance, keep running the library tests under rosetta, which shouldn't take too long.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it may be feasible for rust-lang/rust
to run a subset of tests still for x86_64-apple-darwin
, this RFCs just drops that promise. This wording is somewhat accurate in that it's definitely a possibility for us to not run any tests (as per Tier 2 support level), even if that seems unlikely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that would be good to communicate clearly, also in the blog post: we don't actually plan to drop all tests immediately, we'll continue testing some things under Rosetta where feasible, etc.
Or is our plan really to drop all tests entirely when we stop using the free macos-13 runners?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or is our plan really to drop all tests entirely when we stop using the free macos-13 runners?
I think the intention is to keep that open as a possibility in case it becomes necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, that's what I figured. I think this needs to be quite explicit, or people will conclude that we are dropping all tests immediately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we can necessarily guarantee that
The RFC currently basically suggests that we guarantee that we don't run any tests.
That is not the same as not guaranteeing that we run all the tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The RFC currently basically suggests that we guarantee that we don't run any tests. That is not the same as not guaranteeing that we run all the tests.
So something like
This means that it is no longer guaranteed that the
x86_64-apple-darwin
target will be tested in CI
Which includes the possibility that no tests for x86_64-apple-darwin
is run at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. It's definitely a possibility, but it's a matter of continuous evaluation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this better?
diff --git a/text/3841-demote-x86_64-apple-darwin.md b/text/3841-demote-x86_64-apple-darwin.md
index e1e72361..942446ae 100644
--- a/text/3841-demote-x86_64-apple-darwin.md
+++ b/text/3841-demote-x86_64-apple-darwin.md
@@ -71,7 +71,7 @@ we can see that `x86_64-apple-darwin` has substantially fewer downloads than `aa
The first release after this RFC is merged will be the last one with Tier 1 support for the `x86_64-apple-darwin` target.
The release after that will demote the target to Tier 2 with host tools,
-which means it will not be tested by CI.
+which means we no longer guarantee that it will be tested by CI.
Once this RFC is merged,
a blog post will be published on the main Rust Blog announcing the change to alert users of the demotion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I would prefer that.
Friendly nudge for the remaining FCP reviewers (would not have done so if it's not as time-sensitive), as on 2025-09-01 GitHub will discontinue providing free macOS x86_64 runners for public repositories, which won't leave us a lot of time for doing the demotion accounting for FCP time. |
@rfcbot concern dont-commit-to-dropping-all-test-coverage (Not sure if I can raise concerns here? I'm in t-compiler but not a "maintainer".) I think we shouldn't prescribe in the RFC that we stop all tests. I think we should just say we stop guaranteeing that all tests are run. That's a big difference. The stats show there's still a lot of x86_64-apple users out there, so it's too early to drop all test coverage entirely. |
@rfcbot concern test-coverage-wording
|
Resolving test-coverage-wording concern given positive feedback and wording adjustment. @rfcbot resolve test-coverage-wording |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
This seems extremely early, given that Apple is continuing to support MacOS Intel until 2028 Is the primary issue an inability to provide ongoing support due to GitHub Runner deprecation (which is still largely up in the air, as newer OS images can likely run on AMD64 - see actions/runner-images#12520 ) |
Newer OS images are available for x86_64, but only on the paid large runners. We can only use the free macOS runners. The part of the announcement relevant to us is that |
5a1eaf8
to
414c087
Compare
414c087
to
69b3c2f
Compare
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [rust](https://github.com/rust-lang/rust) | minor | `1.88.0` -> `1.89.0` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>rust-lang/rust (rust)</summary> ### [`v1.89.0`](https://github.com/rust-lang/rust/blob/HEAD/RELEASES.md#Version-1890-2025-08-07) [Compare Source](rust-lang/rust@1.88.0...1.89.0) \========================== <a id="1.89.0-Language"></a> ## Language - [Stabilize explicitly inferred const arguments (`feature(generic_arg_infer)`)](rust-lang/rust#141610) - [Add a warn-by-default `mismatched_lifetime_syntaxes` lint.](rust-lang/rust#138677) This lint detects when the same lifetime is referred to by different syntax categories between function arguments and return values, which can be confusing to read, especially in unsafe code. This lint supersedes the warn-by-default `elided_named_lifetimes` lint. - [Expand `unpredictable_function_pointer_comparisons` to also lint on function pointer comparisons in external macros](rust-lang/rust#134536) - [Make the `dangerous_implicit_autorefs` lint deny-by-default](rust-lang/rust#141661) - [Stabilize the avx512 target features](rust-lang/rust#138940) - [Stabilize `kl` and `widekl` target features for x86](rust-lang/rust#140766) - [Stabilize `sha512`, `sm3` and `sm4` target features for x86](rust-lang/rust#140767) - [Stabilize LoongArch target features `f`, `d`, `frecipe`, `lasx`, `lbt`, `lsx`, and `lvz`](rust-lang/rust#135015) - [Remove `i128` and `u128` from `improper_ctypes_definitions`](rust-lang/rust#137306) - [Stabilize `repr128` (`#[repr(u128)]`, `#[repr(i128)]`)](rust-lang/rust#138285) - [Allow `#![doc(test(attr(..)))]` everywhere](rust-lang/rust#140560) - [Extend temporary lifetime extension to also go through tuple struct and tuple variant constructors](rust-lang/rust#140593) - [`extern "C"` functions on the `wasm32-unknown-unknown` target now have a standards compliant ABI](https://blog.rust-lang.org/2025/04/04/c-abi-changes-for-wasm32-unknown-unknown/) <a id="1.89.0-Compiler"></a> ## Compiler - [Default to non-leaf frame pointers on aarch64-linux](rust-lang/rust#140832) - [Enable non-leaf frame pointers for Arm64EC Windows](rust-lang/rust#140862) - [Set Apple frame pointers by architecture](rust-lang/rust#141797) <a id="1.89.0-Platform-Support"></a> ## Platform Support - [Add new Tier-3 targets `loongarch32-unknown-none` and `loongarch32-unknown-none-softfloat`](rust-lang/rust#142053) - [`x86_64-apple-darwin` is in the process of being demoted to Tier 2 with host tools](rust-lang/rfcs#3841) Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. [platform-support-doc]: https://doc.rust-lang.org/rustc/platform-support.html <a id="1.89.0-Libraries"></a> ## Libraries - [Specify the base path for `file!`](rust-lang/rust#134442) - [Allow storing `format_args!()` in a variable](rust-lang/rust#140748) - [Add `#[must_use]` to `[T; N]::map`](rust-lang/rust#140957) - [Implement `DerefMut` for `Lazy{Cell,Lock}`](rust-lang/rust#129334) - [Implement `Default` for `array::IntoIter`](rust-lang/rust#141574) - [Implement `Clone` for `slice::ChunkBy`](rust-lang/rust#138016) - [Implement `io::Seek` for `io::Take`](rust-lang/rust#138023) <a id="1.89.0-Stabilized-APIs"></a> ## Stabilized APIs - [`NonZero<char>`](https://doc.rust-lang.org/stable/std/num/struct.NonZero.html) - Many intrinsics for x86, not enumerated here - [AVX512 intrinsics](rust-lang/rust#111137) - [`SHA512`, `SM3` and `SM4` intrinsics](rust-lang/rust#126624) - [`File::lock`](https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.lock) - [`File::lock_shared`](https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.lock_shared) - [`File::try_lock`](https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.try_lock) - [`File::try_lock_shared`](https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.try_lock_shared) - [`File::unlock`](https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.unlock) - [`NonNull::from_ref`](https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.from_ref) - [`NonNull::from_mut`](https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.from_mut) - [`NonNull::without_provenance`](https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.without_provenance) - [`NonNull::with_exposed_provenance`](https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.with_exposed_provenance) - [`NonNull::expose_provenance`](https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.expose_provenance) - [`OsString::leak`](https://doc.rust-lang.org/stable/std/ffi/struct.OsString.html#method.leak) - [`PathBuf::leak`](https://doc.rust-lang.org/stable/std/path/struct.PathBuf.html#method.leak) - [`Result::flatten`](https://doc.rust-lang.org/stable/std/result/enum.Result.html#method.flatten) - [`std::os::linux::net::TcpStreamExt::quickack`](https://doc.rust-lang.org/stable/std/os/linux/net/trait.TcpStreamExt.html#tymethod.quickack) - [`std::os::linux::net::TcpStreamExt::set_quickack`](https://doc.rust-lang.org/stable/std/os/linux/net/trait.TcpStreamExt.html#tymethod.set_quickack) These previously stable APIs are now stable in const contexts: - [`<[T; N]>::as_mut_slice`](https://doc.rust-lang.org/stable/std/primitive.array.html#method.as_mut_slice) - [`<[u8]>::eq_ignore_ascii_case`](https://doc.rust-lang.org/stable/std/primitive.slice.html#impl-%5Bu8%5D/method.eq_ignore_ascii_case) - [`str::eq_ignore_ascii_case`](https://doc.rust-lang.org/stable/std/primitive.str.html#impl-str/method.eq_ignore_ascii_case) <a id="1.89.0-Cargo"></a> ## Cargo - [`cargo fix` and `cargo clippy --fix` now default to the same Cargo target selection as other build commands.](rust-lang/cargo#15192) Previously it would apply to all targets (like binaries, examples, tests, etc.). The `--edition` flag still applies to all targets. - [Stabilize doctest-xcompile.](rust-lang/cargo#15462) Doctests are now tested when cross-compiling. Just like other tests, it will use the [`runner` setting](https://doc.rust-lang.org/cargo/reference/config.html#targettriplerunner) to run the tests. If you need to disable tests for a target, you can use the [ignore doctest attribute](https://doc.rust-lang.org/rustdoc/write-documentation/documentation-tests.html#ignoring-targets) to specify the targets to ignore. <a id="1.89.0-Rustdoc"></a> ## Rustdoc - [On mobile, make the sidebar full width and linewrap](rust-lang/rust#139831). This makes long section and item names much easier to deal with on mobile. <a id="1.89.0-Compatibility-Notes"></a> ## Compatibility Notes - [Make `missing_fragment_specifier` an unconditional error](rust-lang/rust#128425) - [Enabling the `neon` target feature on `aarch64-unknown-none-softfloat` causes a warning](rust-lang/rust#135160) because mixing code with and without that target feature is not properly supported by LLVM - [Sized Hierarchy: Part I](rust-lang/rust#137944) - Introduces a small breaking change affecting `?Sized` bounds on impls on recursive types which contain associated type projections. It is not expected to affect any existing published crates. Can be fixed by refactoring the involved types or opting into the `sized_hierarchy` unstable feature. See the [FCP report](rust-lang/rust#137944 (comment)) for a code example. - The warn-by-default `elided_named_lifetimes` lint is [superseded by the warn-by-default `mismatched_lifetime_syntaxes` lint.](rust-lang/rust#138677) - [Error on recursive opaque types earlier in the type checker](rust-lang/rust#139419) - [Type inference side effects from requiring element types of array repeat expressions are `Copy` are now only available at the end of type checking](rust-lang/rust#139635) - [The deprecated accidentally-stable `std::intrinsics::{copy,copy_nonoverlapping,write_bytes}` are now proper intrinsics](rust-lang/rust#139916). There are no debug assertions guarding against UB, and they cannot be coerced to function pointers. - [Remove long-deprecated `std::intrinsics::drop_in_place`](rust-lang/rust#140151) - [Make well-formedness predicates no longer coinductive](rust-lang/rust#140208) - [Remove hack when checking impl method compatibility](rust-lang/rust#140557) - [Remove unnecessary type inference due to built-in trait object impls](rust-lang/rust#141352) - [Lint against "stdcall", "fastcall", and "cdecl" on non-x86-32 targets](rust-lang/rust#141435) - [Future incompatibility warnings relating to the never type (`!`) are now reported in dependencies](rust-lang/rust#141937) - [Ensure `std::ptr::copy_*` intrinsics also perform the static self-init checks](rust-lang/rust#142575) - [`extern "C"` functions on the `wasm32-unknown-unknown` target now have a standards compliant ABI](https://blog.rust-lang.org/2025/04/04/c-abi-changes-for-wasm32-unknown-unknown/) <a id="1.89.0-Internal-Changes"></a> ## Internal Changes These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools. - [Correctly un-remap compiler sources paths with the `rustc-dev` component](rust-lang/rust#142377) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS41NS4yIiwidXBkYXRlZEluVmVyIjoiNDEuNTUuMiIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiUmVub3ZhdGUgQm90Il19-->
Due to decreasing support from github and rust: https://blog.rust-lang.org/2025/08/07/Rust-1.89.0/#demoting-x86-64-apple-darwin-to-tier-2-with-host-tools rust-lang/rfcs#3841 https://github.blog/changelog/2025-07-11-upcoming-changes-to-macos-hosted-runners-macos-latest-migration-and-xcode-support-policy-updates/#macos-13-is-closing-down
Rendered