Skip to content

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

Merged
merged 1 commit into from
Aug 11, 2025

Conversation

shepmaster
Copy link
Member

@shepmaster shepmaster commented Jul 23, 2025

@shepmaster shepmaster added T-compiler Relevant to the compiler team, which will review and decide on the RFC. T-release Relevant to the release team, which will review and decide on the RFC. labels Jul 23, 2025
@shepmaster shepmaster force-pushed the demote-x86_64-apple-darwin branch 2 times, most recently from 84fcc97 to 242cfad Compare July 23, 2025 13:33
@Noratrieb
Copy link
Member

Starting FCP already, we don't have many options here.
@rfcbot fcp merge

@rfcbot
Copy link
Collaborator

rfcbot commented Jul 23, 2025

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.

@rfcbot rfcbot added proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. labels Jul 23, 2025

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.
Copy link
Member

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.

Copy link
Member

@jieyouxu jieyouxu Jul 25, 2025

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.

Copy link
Member

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?

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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?

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

@jieyouxu
Copy link
Member

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.

cc @cjgillot @nagisa @spastorino @wesleywiser

@RalfJung
Copy link
Member

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

@jieyouxu
Copy link
Member

@rfcbot concern test-coverage-wording

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.

-- #3841 (comment)

@jieyouxu
Copy link
Member

Resolving test-coverage-wording concern given positive feedback and wording adjustment.

@rfcbot resolve test-coverage-wording

@rfcbot rfcbot added final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. and removed proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. labels Jul 29, 2025
@rfcbot
Copy link
Collaborator

rfcbot commented Jul 29, 2025

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this RFC. to-announce and removed final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. labels Aug 8, 2025
@rfcbot
Copy link
Collaborator

rfcbot commented Aug 8, 2025

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.

@stacksjb
Copy link

stacksjb commented Aug 8, 2025

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 )

@pietroalbini
Copy link
Member

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 macos-13 is the only x86_64 image available on free runners.

@shepmaster shepmaster force-pushed the demote-x86_64-apple-darwin branch from 5a1eaf8 to 414c087 Compare August 11, 2025 14:51
@shepmaster shepmaster force-pushed the demote-x86_64-apple-darwin branch from 414c087 to 69b3c2f Compare August 11, 2025 14:53
@shepmaster shepmaster merged commit 2ad779b into rust-lang:master Aug 11, 2025
@shepmaster shepmaster deleted the demote-x86_64-apple-darwin branch August 11, 2025 14:54
tmeijn pushed a commit to tmeijn/dotfiles that referenced this pull request Aug 12, 2025
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-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this RFC. T-compiler Relevant to the compiler team, which will review and decide on the RFC. T-release Relevant to the release team, which will review and decide on the RFC. to-announce
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants