[PR #704] [MERGED] fix(native): select concrete arm64e Mach-O slices #2183

New issue

Closed

opened 2026-10-16 21:15:21 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:15:21 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/704
Author: @kaoru0822-kitauji
Created: 10/6/2026
Status: ✅ Merged
Merged: 10/6/2026
Merged by: @kaoru0822-kitauji

Base: main ← Head: fix/arm64e-native-inspection

📝 Commits (1)

fd3282a fix(native): select concrete arm64e Mach-O slices

📊 Changes

2 files changed (+124 additions, -16 deletions)

View changed files

📝 src/native/NativeMachoInspection.ts (+53 -16)
📝 tests/boundary/providers/native/nativeSelectedArchitecture.test.ts (+71 -0)

📄 Description

Summary

inspect lipo -detailed_info before running slice-aware Mach-O tools
recover the concrete arm64e slice when the admitted target has normalized its CPU subtype to arm64
prefer the plain arm64e slice when both arm64e and arm64e.x1 are present
preserve dyld_info's exact arm64e.v1 spelling while using the base arm64e spelling accepted by the other Apple tools

Closes #674.

Evidence

The reported universal targets are admitted with normalized architecture arm64, but their actual slices are arm64e, arm64e.x1, or arm64e.v1. The provider previously constructed every slice-aware command from the normalized target before reading the detailed lipo inventory, so otool -arch arm64 and the following commands failed on files that do not contain an arm64 slice.

The regression routes both reported inventories through the production provider seam:

a /bin/ls-style x86_64 + arm64e + arm64e.x1 inventory must select plain arm64e
a clang-style x86_64 + arm64e.v1 inventory must use arm64e.v1 for dyld_info and arm64e for the other tools

Before the fix, both cases return ProviderAdapterError; afterward they return the selected slice's UUID while retaining every architecture in the normalized inventory.

Validation

Passed:

focused selected-architecture regression: 3 tests
Mach-O header/load/inventory/selection boundary suites: 14 tests
native provider inspection and parsing selection: 11 tests
npm exec --package=typescript@5.9.3 -- tsc --noEmit
npm run lint
npm run knip
npm run metadata:check
targeted oxfmt --check and git diff --check

Materially unverified:

Real Apple tools on macOS were unavailable in this Linux environment; the regression enforces the command/exit behavior reported in #674 through the production runner seam.
The repository's TypeScript 7 binary panics while resolving /proc/self/exe, so npm run check could not complete; the stable TypeScript compiler and the independently run remaining checks passed.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/704 **Author:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Created:** 10/6/2026 **Status:** ✅ Merged **Merged:** 10/6/2026 **Merged by:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Base:** `main` ← **Head:** `fix/arm64e-native-inspection` --- ### 📝 Commits (1) - [`fd3282a`](https://github.com/morluto/rea/commit/fd3282a87e40417cf3d7d6211743809f9bad2dc8) fix(native): select concrete arm64e Mach-O slices ### 📊 Changes **2 files changed** (+124 additions, -16 deletions) <details> <summary>View changed files</summary> 📝 `src/native/NativeMachoInspection.ts` (+53 -16) 📝 `tests/boundary/providers/native/nativeSelectedArchitecture.test.ts` (+71 -0) </details> ### 📄 Description ## Summary - inspect `lipo -detailed_info` before running slice-aware Mach-O tools - recover the concrete arm64e slice when the admitted target has normalized its CPU subtype to `arm64` - prefer the plain `arm64e` slice when both `arm64e` and `arm64e.x1` are present - preserve `dyld_info`'s exact `arm64e.v1` spelling while using the base `arm64e` spelling accepted by the other Apple tools Closes #674. ## Evidence The reported universal targets are admitted with normalized architecture `arm64`, but their actual slices are `arm64e`, `arm64e.x1`, or `arm64e.v1`. The provider previously constructed every slice-aware command from the normalized target before reading the detailed lipo inventory, so `otool -arch arm64` and the following commands failed on files that do not contain an arm64 slice. The regression routes both reported inventories through the production provider seam: - a `/bin/ls`-style `x86_64 + arm64e + arm64e.x1` inventory must select plain `arm64e` - a clang-style `x86_64 + arm64e.v1` inventory must use `arm64e.v1` for `dyld_info` and `arm64e` for the other tools Before the fix, both cases return `ProviderAdapterError`; afterward they return the selected slice's UUID while retaining every architecture in the normalized inventory. ## Validation Passed: - focused selected-architecture regression: 3 tests - Mach-O header/load/inventory/selection boundary suites: 14 tests - native provider inspection and parsing selection: 11 tests - `npm exec --package=typescript@5.9.3 -- tsc --noEmit` - `npm run lint` - `npm run knip` - `npm run metadata:check` - targeted `oxfmt --check` and `git diff --check` Materially unverified: - Real Apple tools on macOS were unavailable in this Linux environment; the regression enforces the command/exit behavior reported in #674 through the production runner seam. - The repository's TypeScript 7 binary panics while resolving `/proc/self/exe`, so `npm run check` could not complete; the stable TypeScript compiler and the independently run remaining checks passed. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-16 21:15:21 +00:00