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

Demote Apple 32bit targets to Tier 3 #2837

Merged
merged 1 commit into from Dec 30, 2019

Conversation

@pietroalbini
Copy link
Member

pietroalbini commented Dec 10, 2019

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

@pietroalbini

This comment has been minimized.

Copy link
Member Author

pietroalbini commented Dec 10, 2019

cc @rust-lang/release @rust-lang/compiler (assigned to the RFC)
cc @rust-lang/infra (interested in it)

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

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Dec 10, 2019

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

This comment has been minimized.

Copy link
@ids1024

ids1024 Dec 11, 2019

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.

This comment has been minimized.

Copy link
@pietroalbini

pietroalbini Dec 11, 2019

Author Member

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.

This comment has been minimized.

Copy link
@gnzlbg

gnzlbg Dec 12, 2019

Contributor

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.

This comment has been minimized.

Copy link
@ids1024

ids1024 Dec 12, 2019

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

@chrisballinger

This comment has been minimized.

Copy link

chrisballinger commented Dec 11, 2019

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.

@pietroalbini

This comment has been minimized.

Copy link
Member Author

pietroalbini commented Dec 11, 2019

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.

@XAMPPRocky

This comment has been minimized.

Copy link

XAMPPRocky commented Dec 11, 2019

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.

@kennytm

This comment has been minimized.

Copy link
Member

kennytm commented Dec 11, 2019

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

@XAMPPRocky

This comment has been minimized.

Copy link

XAMPPRocky commented Dec 11, 2019

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.

@BatmanAoD BatmanAoD mentioned this pull request Dec 11, 2019
@chrisballinger

This comment has been minimized.

Copy link

chrisballinger commented Dec 11, 2019

@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 armv7k and arm64_32 (sorta like x32).

Screen Shot 2019-12-11 at 11 08 34 AM

Either way, Rust has never supported watchOS or tvOS as a supported platform, so feel free to ignore my noise!

@pietroalbini

This comment has been minimized.

Copy link
Member Author

pietroalbini commented Dec 16, 2019

Seems there are no major blockers being raised so far, so, let's go ahead with rfcbot!

@rfcbot merge

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Dec 16, 2019

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.

@pietroalbini

This comment has been minimized.

Copy link
Member Author

pietroalbini commented Dec 16, 2019

If there are no delays, according to the RFC text:

  • Rust 1.41.0 (2020-01-30) will be the last with support for 32bit Apple targets.
  • Rust 1.42.0 (2020-03-12) will have no support them.
@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Dec 19, 2019

@rfcbot reviewed

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Dec 20, 2019

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

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Dec 30, 2019

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.

@pietroalbini pietroalbini merged commit 1b7ccd2 into rust-lang:master Dec 30, 2019
@pietroalbini

This comment has been minimized.

Copy link
Member Author

pietroalbini commented Dec 30, 2019

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:
rust-lang/rust#67724

@pietroalbini pietroalbini deleted the pietroalbini:demote-apple-32bit branch Dec 30, 2019
@fpotter

This comment has been minimized.

Copy link

fpotter commented Jan 3, 2020

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.

bors added a commit to rust-lang/rust that referenced this pull request Jan 7, 2020
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.