Fix unwinding on 32-bit watchOS ARM #124494
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
rustbot has assigned @Mark-Simulacrum. Use |
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
The code is written in a way to support 32-bit iOS and tvOS ARM devices, for future compatibility even though we currently only have a target for 32-bit iOS ARM.
madsmtm
force-pushed
the
fix-32bit-watchos-unwind
branch
from
51ef037
to
39dc6c1
Compare
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 30, 2024
…ngjubilee Use `target_vendor = "apple"` instead of `target_os = "..."` Use `target_vendor = "apple"` instead of `all(target_os = "macos", target_os = "ios", target_os = "tvos", target_os = "watchos", target_os = "visionos")`. The apple targets are quite close to being identical, with iOS, tvOS, watchOS and visionOS being even closer, so using `target_vendor` when possible makes it clearer when something is actually OS-specific, or just Apple-specific. Note that `target_vendor` will [be deprecated in the future](rust-lang#100343), but not before an alternative (like `target_family = "apple"`) is available. While doing this, I found various inconsistencies and small mistakes in the standard library, see the commits for details. Will follow-up with an extra PR for a similar issue that need a bit more discussion. EDIT: rust-lang#124494 Since you've talked about using `target_vendor = "apple"` in the past: r? workingjubilee CC `@simlay,` `@thomcc` `@rustbot` label O-macos O-ios O-tvos O-watchos O-visionos
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 1, 2024
…ngjubilee Use `target_vendor = "apple"` instead of `target_os = "..."` Use `target_vendor = "apple"` instead of `all(target_os = "macos", target_os = "ios", target_os = "tvos", target_os = "watchos", target_os = "visionos")`. The apple targets are quite close to being identical, with iOS, tvOS, watchOS and visionOS being even closer, so using `target_vendor` when possible makes it clearer when something is actually OS-specific, or just Apple-specific. Note that `target_vendor` will [be deprecated in the future](rust-lang#100343), but not before an alternative (like `target_family = "apple"`) is available. While doing this, I found various inconsistencies and small mistakes in the standard library, see the commits for details. Will follow-up with an extra PR for a similar issue that need a bit more discussion. EDIT: rust-lang#124494 Since you've talked about using `target_vendor = "apple"` in the past: r? workingjubilee CC `@simlay,` `@thomcc` `@rustbot` label O-macos O-ios O-tvos O-watchos O-visionos
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
May 3, 2024
Use `target_vendor = "apple"` instead of `target_os = "..."` Use `target_vendor = "apple"` instead of `all(target_os = "macos", target_os = "ios", target_os = "tvos", target_os = "watchos", target_os = "visionos")`. The apple targets are quite close to being identical, with iOS, tvOS, watchOS and visionOS being even closer, so using `target_vendor` when possible makes it clearer when something is actually OS-specific, or just Apple-specific. Note that `target_vendor` will [be deprecated in the future](rust-lang/rust#100343), but not before an alternative (like `target_family = "apple"`) is available. While doing this, I found various inconsistencies and small mistakes in the standard library, see the commits for details. Will follow-up with an extra PR for a similar issue that need a bit more discussion. EDIT: rust-lang/rust#124494 Since you've talked about using `target_vendor = "apple"` in the past: r? workingjubilee CC `@simlay,` `@thomcc` `@rustbot` label O-macos O-ios O-tvos O-watchos O-visionos
|
Everything in here looks good to me, approving from the toolchain perspective, but likewise I cannot test as I don't have a device old enough. |
|
@bors r+ Looks like this is just affecting tier 3 targets, so going to go ahead and approve. |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Sure, I've opened #124748 |
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
May 5, 2024
…r=Mark-Simulacrum Fix unwinding on 32-bit watchOS ARM (v2) This PR is identical to rust-lang#124494, which was approved and merged but then removed from master by a force-push due to a [CI bug](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/ci.20broken.3F). r? Mark-Simulacrum Original PR description: --- Found while doing rust-lang#124491, I wanted to unify the code under `target_vendor = "apple"`, and found that [Clang actually specifies that watchOS ARM 32-bit does not use SjLj](https://github.com/llvm/llvm-project/blob/llvmorg-18.1.4/clang/lib/Driver/ToolChains/Darwin.cpp#L3107-L3119). I don't have an Apple Watch from that generation at hand to test this myself (series 1 to 3), and I don't think it will be sufficient to test it in the simulator (as it's architecture-specific), so maybe someone else could do so? N.B. The code is written in a way to support 32-bit iOS and tvOS ARM devices (which do use SjLj) for future compatibility even though we currently only have a target for 32-bit iOS ARM (if you think that's excessive, then I'll change it). `@rustbot` label O-watchos
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 5, 2024
Rollup merge of rust-lang#124748 - madsmtm:fix-32bit-watchos-unwind, r=Mark-Simulacrum Fix unwinding on 32-bit watchOS ARM (v2) This PR is identical to rust-lang#124494, which was approved and merged but then removed from master by a force-push due to a [CI bug](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/ci.20broken.3F). r? Mark-Simulacrum Original PR description: --- Found while doing rust-lang#124491, I wanted to unify the code under `target_vendor = "apple"`, and found that [Clang actually specifies that watchOS ARM 32-bit does not use SjLj](https://github.com/llvm/llvm-project/blob/llvmorg-18.1.4/clang/lib/Driver/ToolChains/Darwin.cpp#L3107-L3119). I don't have an Apple Watch from that generation at hand to test this myself (series 1 to 3), and I don't think it will be sufficient to test it in the simulator (as it's architecture-specific), so maybe someone else could do so? N.B. The code is written in a way to support 32-bit iOS and tvOS ARM devices (which do use SjLj) for future compatibility even though we currently only have a target for 32-bit iOS ARM (if you think that's excessive, then I'll change it). `@rustbot` label O-watchos
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Found while doing #124491, I wanted to unify the code under
target_vendor = "apple", and found that Clang actually specifies that watchOS ARM 32-bit does not use SjLj.I don't have an Apple Watch from that generation at hand to test this myself (series 1 to 3), and I don't think it will be sufficient to test it in the simulator (as it's architecture-specific), so maybe someone else could do so?
N.B. The code is written in a way to support 32-bit iOS and tvOS ARM devices (which do use SjLj) for future compatibility even though we currently only have a target for 32-bit iOS ARM (if you think that's excessive, then I'll change it).
CC target maintainers @deg4uss3r, @vladimir-ea, @leohowell.
CC @simlay, @thomcc whom might have more insight into this than I.
@rustbot label O-watchos