Demote Apple 32bit targets to Tier 3 #2837
Conversation
pietroalbini
added
T-compiler
|
cc @rust-lang/release @rust-lang/compiler (assigned to the RFC) Unless there are blockers raised in the next week-ish I'd like to propose to merge this soon (of course with the usual checkboxes + FCP). |
|
I'm in favor. I think this is a clear case where we can simplify our maintenance burden. |
| # Prior art | ||
| [prior-art]: #prior-art | ||
|
|
||
| There is no precedent inside the project for the deprecation of Tier 1 targets |
There was a problem hiding this comment.
Perhaps the RFC should say more about the general procedure for this sort of thing?
The justification for demotion seems quite reasonable. But it seems unexpected to me that a tier 1 platform would suddenly become tier 3 from one release to another without much warning. I know demotion to tier 3 isn't "removal", but given the less than straightforward process currently of manually building an std targeting a tier 3 platform, it essentially is removal to typical users.
There was a problem hiding this comment.
Perhaps the RFC should say more about the general procedure for this sort of thing?
I explicitly didn't want to include a general policy about demoting targets: I hope it will be addressed by #2803, and I don't want this RFC to get slowed down while we agree on such a policy.
The justification for demotion seems quite reasonable. But it seems unexpected to me that a tier 1 platform would suddenly become tier 3 from one release to another without much warning. I know demotion to tier 3 isn't "removal", but given the less than straightforward process currently of manually building an std targeting a tier 3 platform, it essentially is removal to typical users.
Unfortunately we don't have much choice on this, sooner or later we're going to have to demote these targets: Apple is actively trying to stop projects from supporting 32bit, as you can't even cross-compile 32bit binaries anymore starting from macOS 10.14.
We don't have any insight on the plans Azure Pipelines has about deprecating build platforms, but we don't expect them to continue providing macOS 10.13 builders forever. I don't expect other CI providers to support that platform after it reaches EOL either.
Once most of the providers offering macOS stop supporting 10.13 we'd then have to build our own build farm, with an out of date, unsupported and potentially vulnerable base OS. That would put even more workload on the already busy infrastructure team, and let's not consider the security risk of doing that.
Unless there are people who actively rely on Apple 32bit support, or other major blockers show up, I don't see why we shouldn't just demote the target soon.
And to be clear, we're happy to support older platforms when it's feasible: all the Linux x86/x86_64 toolchains are built inside a CentOS 5 container to keep supporting Linux 2.6.18, for example. It's just that we don't have the resources to do that if upstream tries to prevent people from doing so.
There was a problem hiding this comment.
but given the less than straightforward process currently of manually building an std targeting a tier 3 platform, it essentially is removal to typical users.
Notice that the process is currently quite straightforward: cargo xbuild --target=i686-apple-darwin just works and would continue to work "as is" if these targets are demoted to tier 3. We use this in libc to build libcore and libc for pretty much most/all tier-1, tier-2 and tier-3 targets for which libc is a reasonable thing to build (including the ios targets mentioned here). This process should become simpler once cargo itself is made "std-aware", at which point you wouldn't even need cargo-xbuild.
There was a problem hiding this comment.
It's great if it's that simple. But I thought cargo-xbuild doesn't support building std? This is mentioned in the CHANGELOG for release v0.4.0 (when it was forked from xargo): "Building std is no longer possible".
If I understand that correctly, and it hasn't changed since then (the README doesn't clearly indicate one way or the other), then I think my statement unfortunately still holds that it's not currently straightforward to use std on a tier 3 platform.
(Std-aware cargo should greatly improve this.)
|
I guess this isn't mentioned here (and I haven't seen a watchOS toolchain for Rust anyway), but 32-bit armv7 is still used for the Apple Watch Series 1-3, which are still supported by Apple. Series 4 and higher is 64-bit but I think uses 32-bit pointer sizes. |
Uh, I wasn't aware of that. Still, seems like starting from April 2020 you'll have to build watchOS apps with Xcode 11 to publish them on the App Store, basically preventing any meaningful usage of such target. |
|
Overall I'm in favour of the change, since this is the first deprecation of a tier 1 target though. I think it might be wise to have a longer deprecation cycle to set precedent, for when we're deprecating targets that are more used. Dropping support after the first release (about 6 weeks) after this is merged feels a little fast. I'd personally be more comfortable with 2 releases (~12 weeks/3 months) from merge, if not doing it as soon as possible is reasonable and the target isn't already causing a significant maintenance burden. |
|
@chrisballinger The main reason of demotion is that Apple stopped supporting those platforms, not that they are 32-bit. This RFC won't reject placing the 32-bit watchOS targets in tier-2, if Xcode within a near future can keep on supporting them. |
|
I'm not sure the Apple Watch would apply anyway. I may be wrong but to submit a Watch app right now you have to provide it as LLVM bitcode not a raw executable, and I don't believe rustc provides a way to compile to bitcode compatible libraries. |
|
@XAMPPRocky I've seen some hacks from time to time that get bitcode working with rustc, but I think Rust's LLVM version needs to match Xcode's, which sometimes it doesn't. @pietroalbini Xcode 11 will still output 32-bit armv7 for watchOS targets in order to support Series 1-3. It just doesn't output 32-bit armv7 code for iOS targets. For the record the two currently supported watchOS architectures are
Either way, Rust has never supported watchOS or tvOS as a supported platform, so feel free to ignore my noise! |
|
Seems there are no major blockers being raised so far, so, let's go ahead with rfcbot! @rfcbot merge |
|
Team member @pietroalbini has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed. 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
added
proposed-final-comment-period
|
If there are no delays, according to the RFC text:
|
|
@rfcbot reviewed |
rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
added
finished-final-comment-period
|
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. The RFC will be merged soon. |
|
Huzzah! The @rust-lang/compiler and @rust-lang/release teams has decided to accept this RFC. To track further discussion, subscribe to the tracking issue here: |
|
I'm late, but... Apple does continue to support 32-bit for iOS devices and the simulator. Using Catalina and Xcode 11.3 with a deployment target set to iOS 10.0 or earlier, I can build an app for i386 and armv7. If I download the iOS 10 simulator and set the simulated device to "iPhone 5", I can run that i386 binary in the simulator on Catalina. iOS 11 was the first release to go 64-bit only, but plenty of apps continue to support iOS 10.0 or below which may run on both 32-bit and 64-bit devices. |
ci: remove 32-bit Apple targets This PR drops the `i686-apple` and `dist-i686-apple` CI builders, as well as removing the `armv7-apple-ios`, `armv7s-apple-ios` and `i386-apple-ios` targets from the `x86_64-apple` CI builder. The change was approved in [RFC 2837](rust-lang/rfcs#2837), and it should land in Rust 1.42 stable (so this cycle). r? @alexcrichton
|
To clear the situation: I hope this RFC should have only drop that I'm a framework author, and have to provide the help for user who deploy to iOS 8~10. Currently, I have to rollback the toolchain and use Rust 1.41.0 for some long time. |
This RFC proposes demoting the following targets to Tier 3:
i686-apple-darwin(from Tier 1)armv7-apple-ios(from Tier 2)armv7s-apple-ios(from Tier 2)i386-apple-ios(from Tier 2)Rendered