[PR #2733] [MERGED] fix(apple): derive dyld environment findings from each traced slice #5351

New issue

Closed

opened 2026-10-31 01:05:57 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:05:57 +00:00

Owner

📋 Pull Request Information

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

Base: main ← Head: fix/issue-2661

📝 Commits (1)

173fde4 fix(apple): derive dyld environment findings from each traced slice

📊 Changes

3 files changed (+74 additions, -15 deletions)

View changed files

📝 src/domain/apple/dylibResolution.ts (+4 -1)
📝 src/domain/apple/dylibResolutionFindings.ts (+14 -14)
📝 tests/boundary/cli/dylibResolutionCli.test.ts (+56 -0)

📄 Description

Fixes #2661.

Problem

deriveFindings (src/domain/apple/dylibResolutionFindings.ts) builds dyld-environment-present findings by looking up each traced root's slice again by architecture name:

facts.slices.find((candidate) => candidate.architecture === architecture)

A universal executable with arm64e and arm64e.x1 slices reports both as arm64e, so both roots resolved to the first slice:

If only the second slice has LC_DYLD_ENVIRONMENT, there is no finding at all.
If both slices have different settings, the first slice's command is reported twice and the second slice's command is missing.

The per-slice images[].slices[].dyld_environment arrays were already correct, so only the derived findings were wrong.

Fix

traceDylibLoading already has the exact slice when it records each root. It now passes { image, slice } pairs to deriveFindings instead of having the findings code re-derive the slice from its name. The unused images lookup parameter is removed.

The public roots ({ image, architecture }) and findings shapes are unchanged, so no schema or catalog change is needed.

Validation

New CLI boundary test, dylibResolutionCli.test.ts > reports each same-named slice's own embedded dyld environment. It runs rea trace-dylib-resolution on a FAT executable with arm64e and arm64e.x1 slices, in two cases: a setting on the second slice only, and distinct settings on both slices. It asserts one dyld-environment-present finding per slice carrying that slice's own setting. It fails on main and passes here.
All dylib-resolution suites pass (5 files, 146 tests). npm run check:fast and format:check pass.

🤖 Generated with Claude Code

_{🔄 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/2733 **Author:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Created:** 10/13/2026 **Status:** ✅ Merged **Merged:** 10/13/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/issue-2661` --- ### 📝 Commits (1) - [`173fde4`](https://github.com/morluto/rea/commit/173fde41ae1ac21d7701611df69dcac667eb9df4) fix(apple): derive dyld environment findings from each traced slice ### 📊 Changes **3 files changed** (+74 additions, -15 deletions) <details> <summary>View changed files</summary> 📝 `src/domain/apple/dylibResolution.ts` (+4 -1) 📝 `src/domain/apple/dylibResolutionFindings.ts` (+14 -14) 📝 `tests/boundary/cli/dylibResolutionCli.test.ts` (+56 -0) </details> ### 📄 Description Fixes #2661. ## Problem `deriveFindings` (`src/domain/apple/dylibResolutionFindings.ts`) builds `dyld-environment-present` findings by looking up each traced root's slice again by architecture name: ```ts facts.slices.find((candidate) => candidate.architecture === architecture) ``` A universal executable with `arm64e` and `arm64e.x1` slices reports both as `arm64e`, so both roots resolved to the first slice: - If only the second slice has `LC_DYLD_ENVIRONMENT`, there is no finding at all. - If both slices have different settings, the first slice's command is reported twice and the second slice's command is missing. The per-slice `images[].slices[].dyld_environment` arrays were already correct, so only the derived findings were wrong. ## Fix `traceDylibLoading` already has the exact slice when it records each root. It now passes `{ image, slice }` pairs to `deriveFindings` instead of having the findings code re-derive the slice from its name. The unused `images` lookup parameter is removed. The public `roots` (`{ image, architecture }`) and `findings` shapes are unchanged, so no schema or catalog change is needed. ## Validation - New CLI boundary test, `dylibResolutionCli.test.ts > reports each same-named slice's own embedded dyld environment`. It runs `rea trace-dylib-resolution` on a FAT executable with `arm64e` and `arm64e.x1` slices, in two cases: a setting on the second slice only, and distinct settings on both slices. It asserts one `dyld-environment-present` finding per slice carrying that slice's own setting. It fails on main and passes here. - All dylib-resolution suites pass (5 files, 146 tests). `npm run check:fast` and `format:check` pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:05:57 +00:00