fix(release): restore watchOS, unbreak visionOS - #7379
Conversation
Two problems, one latent since 2026-07-18. visionOS was broken and no release had caught it. dyn-eval joined perry-runtime's `default` in #6584 and reaches psm three crates down (dyn-eval -> perry-parser -> swc_ecma_parser -> stacker -> psm), whose Mach-O guard enumerates darwin/macos/ios/tvos and omits watchos/visionos -- so both fall through to psm's ELF branch and emit .type/.size, which the Mach-O assembler rejects. Nothing in Perry is involved. release-packages.yml builds these with default features and its last successful run was 2026-07-04, before the regression, so it would have surfaced at the next release. Fixed upstream as rust-lang/stacker#152; until that lands these two build `default` minus `dyn-eval`, losing only runtime `new Function`. watchOS was dropped for a reason that never applied to the triple it ships on. The v0.5.888 note blamed ring 0.17.14's pointer-size assertion -- real, but specific to the ILP32 arm64_32-apple-watchos triple. aarch64-apple-watchos is LP64; ring builds for it, as does perry-ui-watchos. The LP64 device triple and its simulator are restored across all three sites that needed it: the build: cross loop, the build-cross matrix, and bottle staging. arm64_32 stays out until ring is fixed or pinned. Verified per target on stable with the exact feature list the workflow now passes: runtime+static, stdlib+static and the UI crate all build for watchos, watchos-sim, visionos and visionos-sim. library_search.rs already maps _watchos/_watchos_sim, so no compiler-side change was needed. Three stale comments claiming watchOS was dropped, and one asserting the device triple is arm64_32, are corrected -- the second is what kept the platform out for months. Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe release workflow restores LP64 watchOS device and simulator builds, excludes ChangesRelease workflow fixes and changelog
Estimated code review effort: 3 (Moderate) | ~25 minutes Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Two separate problems. One is a latent release breakage; the other kept a platform out for months on a misdiagnosis.
1. visionOS was broken, and no release had caught it
dyn-evaljoinedperry-runtime'sdefaultfeature set in #6584 (2026-07-18). It reachespsmthree crates down —dyn-eval→perry-parser→swc_ecma_parser→stacker→psm— and psm selects its assembly with:watchosandvisionosaren't in that list, so both fall through to the#elseELF branch and emit.type/.size— directives the Mach-O assembler rejects. Nothing in Perry is involved.release-packages.ymlbuilds these targets with default features, and its last successful run was 2026-07-04 — before the regression. The two runs since were cancelled. So this was sitting there waiting for the next release.Fixed upstream: rust-lang/stacker#152. Until that lands, watchOS and visionOS build
defaultminusdyn-eval— the list in the workflow is exactly that, nothing else — so the only capability they lose is runtimenew Functionover a string body. There's aDELETE this branch when it landsmarker on both sites.2. watchOS was dropped for a reason that never applied to the triple it ships on
The v0.5.888 note said:
That's true — and ILP32-specific.
aarch64-apple-watchosis LP64. ring builds for it, and so doesperry-ui-watchos. The note also asserted "watchOS = arm64_32" as though that were the only watchOS triple, which is what made the drop look total.Restored on the LP64 device triple + its simulator, across all three sites that needed it: the
build:cross-compile loop, thebuild-crossmatrix, and the bottle staging step.arm64_32stays out until ring is fixed or pinned.Verification
Per-target
cargo checkon stable, with the exact feature list the workflow now passes:-static-staticaarch64-apple-watchosaarch64-apple-watchos-simaarch64-apple-visionosaarch64-apple-visionos-simcargo checkisn't proof a staticlib emits, so I also ran the real thing —cargo +nightly build -Z build-std=core,std,panic_abort --target aarch64-apple-watchos:A genuine watchOS arm64 archive, not a host build in a differently-named directory.
library_search.rsalready maps_watchos/_watchos_sim(lines 1092–1093), so no compiler-side change was needed.Comments corrected
Three claimed watchOS was dropped; one asserted the device triple is
arm64_32. The second is what kept the platform out — worth fixing precisely rather than deleting, since the ILP32 constraint is still real for that triple.Risk
Release-workflow only; no library or compiler code changes. The
if [ -f ]guards in staging keep the existing degrade-gracefully behavior, so a target that fails to build drops out of the bottle rather than failing the job — same as today.Summary by CodeRabbit
New Features
Bug Fixes