r? @petrochenkov

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

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

@rfcbot fcp merge

Team member @petrochenkov has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Aaron1011
• @Amanieu
• @Mark-Simulacrum
• @aidanhs
• @cjgillot
• @cuviper
• @davidtwco
• @eddyb
• @estebank
• @jdno
• @joshtriplett
• @jyn514
• @kennytm
• @lcnr
• @m-ou-se
• @matthewjasper
• @michaelwoerister
• @nagisa
• @nikomatsakis
• @oli-obk
• @petrochenkov
• @pietroalbini
• @pnkfelix
• @rylev
• @shepmaster
• @the8472
• @wesleywiser
• @yaahc

Concerns:

• needs-blog-post (Raise minimum supported Apple OS versions #104385 (comment))

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

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)?

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.

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.

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

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:

• Zoom, which supports iOS 8 but even they are moving to iOS 11+ in a month from now:

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?

Sigh, same test again. Apparently 10.14 is when LC_BUILD_VERSION replaced LC_VERSION_MIN_MACOSX. Dropped it to 10.13 and confirmed that generates the older linker command that matches the pattern that just failed:

Load command 9
      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.13
      sdk 13.3

@rustbot ready

@bors r=petrochenkov rollup=never

(Marking this as no rollup because it's a little bit spotty)

📌 Commit 2044a2d has been approved by petrochenkov

It is now in the queue for this repository.

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

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

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.

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.

Max RSS (memory usage)

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%)