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

Fixed consistency of Apple simulator target's ABI #103455

Merged
merged 3 commits into from
Nov 3, 2022

Conversation

BlackHoleFox
Copy link
Contributor

Currently there's a few Apple device simulator targets that are inconsistent since some set target_abi = "sim" (the correct thing to do) while a bunch of others don't set anything (""). Due to this its very hard to reliability check if some Rust code is running inside a simulator. This changes all of them to do the same thing and set sim as their target_abi.

The new way to identity a simulator during compilation is as simple as cfg(all(target_vendor="apple", target_abi = "sim")) or even cfg(target_abi = "sim") being less pedantic about it.

The issues with the current form (and inspiration for this) are also summarized in @thomcc's Tweet.

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 23, 2022
@rust-highfive
Copy link
Collaborator

r? @compiler-errors

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive
Copy link
Collaborator

⚠️ Warning ⚠️

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 23, 2022
@thomcc
Copy link
Member

thomcc commented Oct 27, 2022

I'm not a reviewer for compiler changes, but FWIW this looks right to me.

@compiler-errors
Copy link
Member

r? compiler

@rustbot rustbot assigned davidtwco and unassigned compiler-errors Oct 27, 2022
Copy link
Member

@davidtwco davidtwco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but I'm not entirely sure what the implications of changing this is for users of these targets.

@thomcc
Copy link
Member

thomcc commented Nov 2, 2022

LGTM, but I'm not entirely sure what the implications of changing this is for users of these targets.

Previously we only had target_abi = "sim" set on some of these, and others you just had to "know" -- for example the aarch64-apple-ios-sim target sets target_abi = "sim", and x86_64-apple-ios (which is a simulator target) does not. We also don't expose the information any other way for x86_64-apple-ios, you have to "know" that it's a simulator target because "real" iOS never shipped on x86_64.... Sort of.

This got worse when Apple released a way for iOS apps to be built and run on macOS (called Catalyst). We expose these via the -ios-macabi targets, for example x86_64-apple-ios-macabi and aarch64-apple-ios-macabi. Now that these exist all(target_os = "ios", target_arch = "x86_64") isn't enough to detect the x86_64 simulator, you have to also include not(target_abi = "macabi").

So, if you want to fully cfg on "am I in the iOS simulator", it gets pretty hairy to handle all the cases. As I mentioned in a tweet, it's something like this:

#[cfg(all(target_os = "ios", any(target_abi = "sim", all(target_arch = "x86_64", not(target_abi = "macabi")))))]

That will work before or after this lands, but is tricky to write and requires a bunch of knowledge about how things work. after this, you can just write

#[cfg(all(target_os = "ios", target_abi = "sim"))]

And have it work fully. Note that this already does work today on aarch64-apple-ios-sim, just not on any of the others.

Also, this makes the tvos and watchos simulator targets consistent too -- previously they were similarly busted.

@davidtwco
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Nov 2, 2022

📌 Commit ffccfa1 has been approved by davidtwco

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 Nov 2, 2022
@bors
Copy link
Contributor

bors commented Nov 3, 2022

⌛ Testing commit ffccfa1 with merge ce1a7e4...

@bors
Copy link
Contributor

bors commented Nov 3, 2022

☀️ Test successful - checks-actions
Approved by: davidtwco
Pushing ce1a7e4 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 3, 2022
@bors bors merged commit ce1a7e4 into rust-lang:master Nov 3, 2022
@rustbot rustbot added this to the 1.67.0 milestone Nov 3, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (ce1a7e4): comparison URL.

Overall result: ✅ improvements - 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)
- - 0
Regressions ❌
(secondary)
1.1% [1.1%, 1.1%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.2% [-2.8%, -1.6%] 6
All ❌✅ (primary) - - 0

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)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.3% [-3.3%, -3.3%] 1
All ❌✅ (primary) - - 0

Cycles

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

@BlackHoleFox BlackHoleFox deleted the apple-sim-abi-consistency branch November 3, 2022 14:21
Manishearth added a commit to Manishearth/rust that referenced this pull request Nov 9, 2022
…, r=petrochenkov

Cleanup Apple-related code in rustc_target

While working on rust-lang#103455, the consistency of the `rustc_target` code for Apple's platforms was "kind of bad." There were two "base" files (`apple_base.rs` and `apple_sdk_base.rs`) that the targets each pulled some parts out of, each and all of them were written slightly differently, and sometimes missed comments other implementations had.

So to hopefully make future maintenance, like implementing rust-lang/compiler-team#556, easier, this makes all of them use similar patterns and the same target base logic everywhere instead of picking bits from both. This also has some other smaller upsides like less stringly-typed functions.
Manishearth added a commit to Manishearth/rust that referenced this pull request Nov 9, 2022
…, r=petrochenkov

Cleanup Apple-related code in rustc_target

While working on rust-lang#103455, the consistency of the `rustc_target` code for Apple's platforms was "kind of bad." There were two "base" files (`apple_base.rs` and `apple_sdk_base.rs`) that the targets each pulled some parts out of, each and all of them were written slightly differently, and sometimes missed comments other implementations had.

So to hopefully make future maintenance, like implementing rust-lang/compiler-team#556, easier, this makes all of them use similar patterns and the same target base logic everywhere instead of picking bits from both. This also has some other smaller upsides like less stringly-typed functions.
Aaron1011 pushed a commit to Aaron1011/rust that referenced this pull request Jan 6, 2023
…cy, r=davidtwco

Fixed consistency of Apple simulator target's ABI

Currently there's a few Apple device simulator targets that are inconsistent since some set `target_abi = "sim"` (the correct thing to do) while a bunch of others don't set anything (`""`). Due to this its very hard to reliability check if some Rust code is running inside a simulator. This changes all of them to do the same thing and set `sim` as their `target_abi`.

The new way to identity a simulator during compilation is as simple as `cfg(all(target_vendor="apple", target_abi = "sim"))` or even `cfg(target_abi = "sim")` being less pedantic about it.

The issues with the current form (and inspiration for this) are also summarized in `@thomcc's` [Tweet](https://twitter.com/at_tcsc/status/1576685244702691328).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants