Skip to content
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

Raise minimum supported Apple OS versions #104385

Merged
merged 3 commits into from
Sep 24, 2023

Conversation

BlackHoleFox
Copy link
Contributor

This implements the proposal to raise the minimum supported Apple OS versions as laid out in the now-completed MCP (rust-lang/compiler-team#556).

As of this PR, rustc and the stdlib now support these versions as the baseline:

  • macOS: 10.12 Sierra
  • iOS: 10
  • tvOS: 10
  • watchOS: 5 (Unchanged)

In addition to everything this breaks indirectly, these changes also erase the armv7-apple-ios target (currently tier 3) because the oldest supported iOS device now uses ARMv7s. Not sure what the policy around tier3 target removal is but shimming it is not an option due to the linker refusing.

Per comment, this requires a FCP to merge. cc @wesleywiser.

@rustbot
Copy link
Collaborator

rustbot commented Nov 14, 2022

r? @petrochenkov

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) A-meta Area: Issues & PRs about the rust-lang/rust repository itself 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. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Nov 14, 2022
@rustbot
Copy link
Collaborator

rustbot commented Nov 14, 2022

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

These commits modify compiler targets.
(See the Target Tier Policy.)

@thomcc thomcc added the needs-fcp This change is insta-stable, so needs a completed FCP to proceed. label Nov 14, 2022
@BlackHoleFox BlackHoleFox changed the title Apple minimum bumps Raise minumum supported Apple OS versions Nov 14, 2022
@BlackHoleFox BlackHoleFox changed the title Raise minumum supported Apple OS versions Raise minimum supported Apple OS versions Nov 14, 2022
@petrochenkov
Copy link
Contributor

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Nov 14, 2022

Team member @petrochenkov 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 Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Nov 14, 2022
@petrochenkov petrochenkov added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 14, 2022
@inquisitivecrystal inquisitivecrystal added the relnotes Marks issues that should be documented in the release notes of the next release. label Nov 14, 2022
@Mark-Simulacrum
Copy link
Member

The relevant MCP has some discussion of not matching Swift's support for macOS 10.9+, but it doesn't have discussion of Python 3 and Julia both supporting that same level. Can we have more discussion of the differences in Rust's story vs. those languages? Is there something that's uniquely hard about what we're doing, or want to do, that makes keeping support for longer more difficult? It seems to me that Julia at least should be in a relatively similar position to our standard library.

Looking at the MCP, it seems like we're justifying the increase for iOS due to usage statistics -- I'd be curious to see similar statistics for macOS. My own sense is that people much more readily update to new iOS versions (and new phone hardware in general) in comparison to the macOS market, which can be retained for much longer.

Not raising a concern here yet, but I personally don't think we ought to be moving the version up for macOS without a clearer story around what Python 3 and Julia are doing in this space. I think this for me is mostly about looking forward to the next bump -- it seems fairly clear we'll be able to write a similar list of desired APIs for some future macOS version (or, say, because we want to drop x86_64 macOS support) -- I think something stronger than just a set of desired APIs would be good.


I think we should also see a post like https://blog.rust-lang.org/2022/08/01/Increasing-glibc-kernel-requirements.html for this to pre-announce the change.

@rfcbot concern needs-blog-post

@madsmtm
Copy link
Contributor

madsmtm commented Nov 16, 2022

A thing to note is that not all devices are capable of upgrading to a certain release; so bumping the minimum version makes it impossible to run software built with Rust on those. To summarize:

Going above iOS 7.0 drops support for:

  • iPhone 4

Going above iOS 9.0 drops support for:

  • iPhone 4S
  • iPad 2
  • iPad (3rd generation)
  • iPad Mini (1st generation)
  • iPod Touch (5th generation)

Going above macOS 10.11 drops support for:

  • A lot of Mac models produced between 2007 and 2009, I won't reproduce the entire list here

Going above tvOS 7.0 drops support for:

  • Apple TV (gen 3)

source, source, source.


This change concretely affects me as iOS maintainer of winit, since the only iOS device that I have easily available to test with is an old iPad Mini (1st generation), which is stuck on iOS 9.0 and uses armv7-apple-ios.

So looking at the above data, perhaps it would make sense to only bump the versions to at a maximum of macOS 10.11 and iOS 9.0 (and some version of tvOS that matches that)?

@cuviper
Copy link
Member

cuviper commented Nov 16, 2022

bumping the minimum version makes it impossible to run software built with Rust on those.

The change will block you from using future Rust versions, but you can continue using older Rust, of course.
(Subject to the MSRV policy of all your dependencies...)

This change concretely affects me as iOS maintainer of winit, since the only iOS device that I have easily available to test with is an old iPad Mini (1st generation), which is stuck on iOS 9.0 and uses armv7-apple-ios.

If you're interested, new hardware might be worth a grant from the foundation, although the application window just closed for this period of project grants. Financial hardship grants are always open.

@madsmtm
Copy link
Contributor

madsmtm commented Nov 16, 2022

That was my actually technically grounded arguments, now for an opinion: I don't think we should raise the OS version above that which is offered by other languages (with the exception of the C-family of languages), simply because I fear that it may be used as an argument for choosing another language over Rust.

So that would mean we should (attempt to) support macOS 10.9, iOS 7.0, watchOS 2.0 and tvOS 9.0, and support those for at least as long as Swift does.

This is speaking even as the developer of a Rust interface to Objective (objc2), that has to resort to using slightly worse APIs simply because newer ones are not universally available.

But yeah, I get it, it's tough to support old devices, and I don't actually know how much of a hazzle it is for you, so no hard feelings whatever you decide.

@jyn514
Copy link
Member

jyn514 commented Nov 17, 2022

Previous discussion: https://rust-lang.zulipchat.com/#narrow/stream/233931-xxx/topic/Raise.20minimum.20supported.20macOS.20and.20iOS.20ver.E2.80.A6.20compiler-team.23556

rustc and the standard library currently support back to macOS 10.7 (OSX Lion) and iOS 7. However, both of these versions have long since been marked deprecated and unsupported by Apple, not having received an update for 9 to 8 years, respectively.

I personally find this pretty convincing.

@rustbot second

@rustbot

This comment was marked as resolved.

@BlackHoleFox
Copy link
Contributor Author

BlackHoleFox commented Nov 17, 2022

I'm gonna reply to @madsmtm's comments first since I'm a bit tired from work and Swift/devices is something easier for me to talk about, then try to answer around @Mark-Simulacrum's comments:

so bumping the minimum version makes it impossible to run software built with Rust on those...

This is something that I was aware of when writing up and the MCP and hopefully something I didn't take too lightly because I used to be in the group that could only work with really old Apple devices. Looking at them in a rough order, while I can't find any hard numbers/graphs for models themselves:

iPhone 4s... (& iOS...)

Wikipedia says that its last update was iOS 9 (3.5 years ago). The phone itself is 11 years old as of last month. Rehashing some things I noted in the MCP, iOS 9 is currently the minimum you're allowed to submit apps/updates with as of earlier this year. XCode 13 (whats now required) is also the last thing to support the armv7 target. Given Apple's cadence of ~2 XCodes per minimum version raise...

  • XCode 14+: 11-xx
  • XCode 13 & XCode 12: 9-xx
  • XCode 10 & XCode 11: 8-xx

...which makes me fairly sure iOS 9 will no longer work for new submissions in a year or two from now. Even if we did consider keeping it, we would end up with a dead target pretty quickly.

If you look through the most downloaded iOS apps (best way I could get an idea of what "the ecosystem" tracks for minimum app versions but I'm open to other suggestions) almost all of them support iOS 10 or higher, with the exceptions of:

Starting December 2022, Zoom will be ending support for iOS 10 and below. You will need to be on iOS 11 or later in order to continue receiving updates.

  • Shadowrocket (proxy manager?) which supports iOS 9+ per the in-progress minimum deployment version allowed for new submissions.
  • Roblox (iOS 9+)
  • CoD Mobile (iOS 9+)
  • Plague Inc (iOS 9+)
  • True Skate (iOS 9+)
  • Geometry Dash (iOS 8+, hasn't been updated in 5 years and is apparently broken on newer iOS versions?)
  • GTA (iOS 8+, hasn't been updated in 3.5 years)

The above definitely doesn't cover the apps everyone uses but it shows a pretty clear trend: The apps with the largest documented number of users are comfortable raising their minimum versions beyond the baseline and games usually follow the minimum. All of the above applies to the other devices stated too. With that, I think that I feel fine saying we won't be hurting the chances of Rust adoption on iOS with this proposal as it stands.

Apple TV (gen 3)

tvOS development seems to be a fairly uncommon thing compared to iOS and we currently don't support it all of the way (#103503) as well. I looked at the top ~15 downloaded tvOS apps and they're all within tvOS 10+. For fun I checked the app's I've personally ran into and Hidive is the only one with a minimum of tvOS 9+. This is obviously not conclusive though.

and support those for at least as long as Swift does.

Similar to the section on the MCP, I don't think that this is a fair assumption to put on a third-party language with no runtime. Apple has put in an insane amount of work to continue support for Swift and Objective-C to be compatible as far back as it is. They're able to build workarounds etc into the frameworks that ship with the system. Rust, obviously, can't do that. Looking at Swift alone, I should call out that anything below macOS 10.14 requires you to bundle a copy of the Swift runtime with your app. If Rust supported a compatibility runtime, I would be more inclined to keep more versions supported but we just don't have the same resources and design Apple does.

To reply with an opinion for your own, I really don't think anyone is still writing new "native" apps that are interested in targeting these very outdated versions so I don't think this will hurt Rust's adoption.

...that has to resort to using slightly worse APIs simply because newer ones are not universally available.

@madsmtm something that may be of interest to you as the objc2 maintainer is Apple cleaning up legacy Objective-C features with Darwin 16:

Objective-C garbage collector removed and replaced by Automatic Reference Counting that was introduced with Darwin v12.0 (OS X v10.8). Objective-C applications that use garbage collection will no longer work.

imo this would be a big boost for anything that uses cc plus objective-C as it gets rid of the error-prone and hard-to-use manual retain/release semantics. I don't think this helps out objc2 directly though but maybe there are similar things that would now become more available?

@thomcc thomcc added O-macos Operating system: macOS O-ios Operating system: iOS labels Nov 17, 2022
@bors
Copy link
Contributor

bors commented Sep 24, 2023

📌 Commit 2044a2d has been approved by petrochenkov

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 24, 2023
@bors
Copy link
Contributor

bors commented Sep 24, 2023

⌛ Testing commit 2044a2d with merge 42ca6e4...

@bors
Copy link
Contributor

bors commented Sep 24, 2023

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 42ca6e4 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 24, 2023
@bors bors merged commit 42ca6e4 into rust-lang:master Sep 24, 2023
12 checks passed
@rustbot rustbot added this to the 1.74.0 milestone Sep 24, 2023
@BlackHoleFox
Copy link
Contributor Author

Blogpost (rust-lang/blog.rust-lang.org#1140) has been updated with a 1.74 release date, its ready for more (final?) reviews and hopefully publishing.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (42ca6e4): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
1.3% [1.3%, 1.3%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.3% [1.3%, 1.3%] 1

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
2.1% [2.1%, 2.1%] 1
Improvements ✅
(primary)
-2.8% [-2.8%, -2.8%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -2.8% [-2.8%, -2.8%] 1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 629.123s -> 630.937s (0.29%)
Artifact size: 317.13 MiB -> 317.15 MiB (0.01%)

@BlackHoleFox BlackHoleFox deleted the apple-minimum-bumps branch September 24, 2023 17:20
bors added a commit to rust-lang/libc that referenced this pull request Sep 25, 2023
Drop `armv7-apple-ios` target support

... as rust-lang/rust#104385 removed the target.
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 24, 2023
…omcc

Remove Apple RNG fallbacks and simplify implementation

Now that we have [higher Apple platform requirements](rust-lang#104385), the RNG code can be simplified a lot. Since `getentropy` still doesn't look to be usable outside macOS this implementation:
- Removes any macOS fallback paths and unconditionally links to `getentropy`
- Minimizes the implementation for everything else (iOS, watchOS, etc).

`CCRandomGenerateBytes` was added in iOS 8 which means that we can use it now. It and `SecRandomCopyBytes` have the exact same functionality, but the former has a simpler API and no longer requires libstd to link to `Security.framework` for one function. Its also available in all the other target's SDKs.

Why care about `getentropy` then though on macOS? Well, its still much more performant. Benchmarking shows it runs at ~2x the speed of `CCRandomGenerateBytes`, which makes sense since it directly pulls from the kernel vs going through its own generator etc.

Semi-related to a previous, but reverted, attempt at improving this logic in rust-lang#101011
madsmtm added a commit to madsmtm/objc2 that referenced this pull request Nov 23, 2023
The versions supported by Rust was updated in rust-lang/rust#104385 to:
- macOS: 10.12 Sierra
- iOS: 10.0
- tvOS: 10.0
- watchOS: 5.0

Additionally, the armv7-apple-ios target was removed.

Finally, since v1.0.84 of `cc` (has been yanked, but 1.0.85 will include it as well), there is much better support for specifying the deployment target for Apple targets, so I've removed the corresponding code from objc-sys.
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Jan 8, 2024
Pkgsrc changes:

 * Remove NetBSD-8 support (embedded LLVm requires newer C++
   than what is in -8; it's conceivable that this could still
   build with an external LLVM)
 * undo powerpc 9.0 file naming tweak, since we no longer support -8.
 * Remove patch to LLVM for powerpc now included by upstream.
 * Minor adjustments, checksum changes etc.


Upstream changes:

Version 1.74.1 (2023-12-07)
===========================

- [Resolved spurious STATUS_ACCESS_VIOLATIONs in LLVM]
  (rust-lang/rust#118464)
- [Clarify guarantees for std::mem::discriminant]
  (rust-lang/rust#118006)
- [Fix some subtyping-related regressions]
  (rust-lang/rust#116415)

Version 1.74.0 (2023-11-16)
==========================

Language
--------

- [Codify that `std::mem::Discriminant<T>` does not depend on any
  lifetimes in T]
  (rust-lang/rust#104299)
- [Replace `private_in_public` lint with `private_interfaces` and
  `private_bounds` per RFC 2145]
  (rust-lang/rust#113126)
  Read more in
  [RFC 2145](https://rust-lang.github.io/rfcs/2145-type-privacy.html).
- [Allow explicit `#[repr(Rust)]`]
  (rust-lang/rust#114201)
- [closure field capturing: don't depend on alignment of packed fields]
  (rust-lang/rust#115315)
- [Enable MIR-based drop-tracking for `async` blocks]
  (rust-lang/rust#107421)

Compiler
--------

- [stabilize combining +bundle and +whole-archive link modifiers]
  (rust-lang/rust#113301)
- [Stabilize `PATH` option for `--print KIND=PATH`]
  (rust-lang/rust#114183)
- [Enable ASAN/LSAN/TSAN for `*-apple-ios-macabi`]
  (rust-lang/rust#115644)
- [Promote loongarch64-unknown-none* to Tier 2]
  (rust-lang/rust#115368)
- [Add `i686-pc-windows-gnullvm` as a tier 3 target]
  (rust-lang/rust#115687)

Libraries
---------

- [Implement `From<OwnedFd/Handle>` for ChildStdin/out/err]
  (rust-lang/rust#98704)
- [Implement `From<{&,&mut} [T; N]>` for `Vec<T>` where `T: Clone`]
  (rust-lang/rust#111278)
- [impl Step for IP addresses]
  (rust-lang/rust#113748)
- [Implement `From<[T; N]>` for `Rc<[T]>` and `Arc<[T]>`]
  (rust-lang/rust#114041)
- [`impl TryFrom<char> for u16`]
  (rust-lang/rust#114065)
- [Stabilize `io_error_other` feature]
  (rust-lang/rust#115453)
- [Stabilize the `Saturating` type]
  (rust-lang/rust#115477)
- [Stabilize const_transmute_copy]
  (rust-lang/rust#115520)

Stabilized APIs
---------------

- [`core::num::Saturating`]
  (https://doc.rust-lang.org/stable/std/num/struct.Saturating.html)
- [`impl From<io::Stdout> for std::process::Stdio`]
  (https://doc.rust-lang.org/stable/std/process/struct.Stdio.html#impl-From%3CStdout%3E-for-Stdio)
- [`impl From<io::Stderr> for std::process::Stdio`]
  (https://doc.rust-lang.org/stable/std/process/struct.Stdio.html#impl-From%3CStderr%3E-for-Stdio)
- [`impl From<OwnedHandle> for std::process::Child{Stdin, Stdout, Stderr}`]
  (https://doc.rust-lang.org/stable/std/process/struct.Stdio.html#impl-From%3CStderr%3E-for-Stdio)
- [`impl From<OwnedFd> for std::process::Child{Stdin, Stdout, Stderr}`]
  (https://doc.rust-lang.org/stable/std/process/struct.Stdio.html#impl-From%3CStderr%3E-for-Stdio)
- [`std::ffi::OsString::from_encoded_bytes_unchecked`]
  (https://doc.rust-lang.org/stable/std/ffi/struct.OsString.html#method.from_encoded_bytes_unchecked)
- [`std::ffi::OsString::into_encoded_bytes`]
  (https://doc.rust-lang.org/stable/std/ffi/struct.OsString.html#method.into_encoded_bytes)
- [`std::ffi::OsStr::from_encoded_bytes_unchecked`]
  (https://doc.rust-lang.org/stable/std/ffi/struct.OsStr.html#method.from_encoded_bytes_unchecked)
- [`std::ffi::OsStr::as_encoded_bytes`]
  (https://doc.rust-lang.org/stable/std/ffi/struct.OsStr.html#method.as_encoded_bytes)
- [`std::io::Error::other`]
  (https://doc.rust-lang.org/stable/std/io/struct.Error.html#method.other)
- [`impl TryFrom<char> for u16`]
  (https://doc.rust-lang.org/stable/std/primitive.u16.html#impl-TryFrom%3Cchar%3E-for-u16)
- [`impl<T: Clone, const N: usize> From<&[T; N]> for Vec<T>`]
  (https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#impl-From%3C%26%5BT;+N%5D%3E-for-Vec%3CT,+Global%3E)
- [`impl<T: Clone, const N: usize> From<&mut [T; N]> for Vec<T>`]
  (https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#impl-From%3C%26mut+%5BT;+N%5D%3E-for-Vec%3CT,+Global%3E)
- [`impl<T, const N: usize> From<[T; N]> for Arc<[T]>`]
  (https://doc.rust-lang.org/stable/std/sync/struct.Arc.html#impl-From%3C%5BT;+N%5D%3E-for-Arc%3C%5BT%5D,+Global%3E)
- [`impl<T, const N: usize> From<[T; N]> for Rc<[T]>`]
  (https://doc.rust-lang.org/stable/std/rc/struct.Rc.html#impl-From%3C%5BT;+N%5D%3E-for-Rc%3C%5BT%5D,+Global%3E)

These APIs are now stable in const contexts:

- [`core::mem::transmute_copy`]
  (https://doc.rust-lang.org/beta/std/mem/fn.transmute_copy.html)
- [`str::is_ascii`]
  (https://doc.rust-lang.org/beta/std/primitive.str.html#method.is_ascii)
- [`[u8]::is_ascii`]
  (https://doc.rust-lang.org/beta/std/primitive.slice.html#method.is_ascii)

Cargo
-----

- [fix: Set MSRV for internal packages]
  (rust-lang/cargo#12381)
- [config: merge lists in precedence order]
  (rust-lang/cargo#12515)
- [fix(update): Clarify meaning of --aggressive as --recursive]
  (rust-lang/cargo#12544)
- [fix(update): Make `-p` more convenient by being positional]
  (rust-lang/cargo#12545)
- [feat(help): Add styling to help output ]
  (rust-lang/cargo#12578)
- [feat(pkgid): Allow incomplete versions when unambigious]
  (rust-lang/cargo#12614)
- [feat: stabilize credential-process and registry-auth]
  (rust-lang/cargo#12649)
- [feat(cli): Add '-n' to dry-run]
  (rust-lang/cargo#12660)
- [Add support for `target.'cfg(..)'.linker`]
  (rust-lang/cargo#12535)
- [Stabilize `--keep-going`]
  (rust-lang/cargo#12568)
- [feat: Stabilize lints]
  (rust-lang/cargo#12648)

Rustdoc
-------

- [Add warning block support in rustdoc]
  (rust-lang/rust#106561)
- [Accept additional user-defined syntax classes in fenced code blocks]
  (rust-lang/rust#110800)
- [rustdoc-search: add support for type parameters]
  (rust-lang/rust#112725)
- [rustdoc: show inner enum and struct in type definition for concrete type]
  (rust-lang/rust#114855)

Compatibility Notes
-------------------

- [Raise minimum supported Apple OS versions]
  (rust-lang/rust#104385)
- [make Cell::swap panic if the Cells partially overlap]
  (rust-lang/rust#114795)
- [Reject invalid crate names in `--extern`]
  (rust-lang/rust#116001)
- [Don't resolve generic impls that may be shadowed by dyn built-in impls]
  (rust-lang/rust#114941)

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.

None this cycle.
tamuratak pushed a commit to tamuratak/objc2 that referenced this pull request Mar 13, 2024
The versions supported by Rust was updated in rust-lang/rust#104385 to:
- macOS: 10.12 Sierra
- iOS: 10.0
- tvOS: 10.0
- watchOS: 5.0

Additionally, the armv7-apple-ios target was removed.

Finally, since v1.0.84 of `cc` (has been yanked, but 1.0.85 will include it as well), there is much better support for specifying the deployment target for Apple targets, so I've removed the corresponding code from objc-sys.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-meta Area: Issues & PRs about the rust-lang/rust repository itself A-testsuite Area: The testsuite used to check the correctness of rustc disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. merged-by-bors This PR was explicitly merged by bors. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. O-ios Operating system: iOS O-macos Operating system: macOS O-unix Operating system: Unix-like relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.