[PR #1955] [MERGED] fix(managed): share first-match member list ownership

bsakaguchi commented

2026-10-31 00:57:07 +00:00

Owner

📋 Pull Request Information

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

Base: main ← Head: fix/issue-1953

📝 Commits (2)

2b6762b fix(managed): share first-match member list ownership
5d33bd7 fix(managed): reconcile member ownership with main

📊 Changes

1 file changed (+6 additions, -2 deletions)

View changed files

📝 src/dotnet/ManagedMemberOwnership.test.ts (+6 -2)

📄 Description

Fixes #1953

Behavior

inspect_managed_members resolved field and method owners with createDeclaringTypeLookup. That function binary-searched ordered TypeDef member lists, but fell back to scanning every type for each member when any range was reversed or out of order. With one reversed range first and the owner last, lookups took 8.1 s for 100,000 types.

Inventory attribute lookups (#1943) and the members inspector now share firstMatchListOwners in ManagedMemberPointers.ts. It is one near-linear index over one-based list positions that skips already-owned positions, so overlapping or reversed ranges keep their previous first-match owner.

Removed the ordered/binary-search versus linear-fallback split, and the production declaringType scan. That scan now lives only in ManagedMemberInspectorCore.test.ts, as the property-test oracle.
createDeclaringTypeLookup takes the member-list row count, so positions outside 1..count (including 0, NaN, ±Infinity) have no owner. Callers only pass positions from memberListRowLookup, which are always in range.
The inventory now reserves only its retained owner index in the decode budget, not transient build arrays.

Still separate: the inventory reads TypeDef method-list starts directly instead of calling typeRanges. typeRanges also decodes every type name, field list and parse issue, which would add that work and those issues to inspect_managed_artifact.

Validation

New test resolves members of unordered ranges without rescanning every type: 8.1 s on the previous lookup against a 2 s bound; passes here. The existing property test now compares one-based positions with the first-match oracle. All 171 src/dotnet tests pass.
npm run lint, npm run typecheck, npm run format:check, npm run knip: pass. jscpd is 2.599% (threshold 2.6%).
npm test: 8,345 passed, 12 failed. These are the same 12 that fail on a clean origin/main worktree on this Mac: ibtool NIB tests, the hdiutil verify refusal, and JS runtime discovery paths under /private/var.
Not verified against real compiled .NET assemblies; none are on this machine.

🤖 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/1955 **Author:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Created:** 10/11/2026 **Status:** ✅ Merged **Merged:** 10/11/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/issue-1953` --- ### 📝 Commits (2) - [`2b6762b`](https://github.com/morluto/rea/commit/2b6762bb304110a9a4fbbee3b28c1e3a5ca0453f) fix(managed): share first-match member list ownership - [`5d33bd7`](https://github.com/morluto/rea/commit/5d33bd7f1380293fe64a863aabaebb129094b519) fix(managed): reconcile member ownership with main ### 📊 Changes **1 file changed** (+6 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `src/dotnet/ManagedMemberOwnership.test.ts` (+6 -2) </details> ### 📄 Description Fixes #1953 ## Behavior `inspect_managed_members` resolved field and method owners with `createDeclaringTypeLookup`. That function binary-searched ordered TypeDef member lists, but fell back to scanning every type for each member when any range was reversed or out of order. With one reversed range first and the owner last, lookups took 8.1 s for 100,000 types. Inventory attribute lookups (#1943) and the members inspector now share `firstMatchListOwners` in `ManagedMemberPointers.ts`. It is one near-linear index over one-based list positions that skips already-owned positions, so overlapping or reversed ranges keep their previous first-match owner. ## Related cleanup - Removed the ordered/binary-search versus linear-fallback split, and the production `declaringType` scan. That scan now lives only in `ManagedMemberInspectorCore.test.ts`, as the property-test oracle. - `createDeclaringTypeLookup` takes the member-list row count, so positions outside `1..count` (including 0, NaN, ±Infinity) have no owner. Callers only pass positions from `memberListRowLookup`, which are always in range. - The inventory now reserves only its retained owner index in the decode budget, not transient build arrays. Still separate: the inventory reads TypeDef method-list starts directly instead of calling `typeRanges`. `typeRanges` also decodes every type name, field list and parse issue, which would add that work and those issues to `inspect_managed_artifact`. ## Validation - New test `resolves members of unordered ranges without rescanning every type`: 8.1 s on the previous lookup against a 2 s bound; passes here. The existing property test now compares one-based positions with the first-match oracle. All 171 `src/dotnet` tests pass. - `npm run lint`, `npm run typecheck`, `npm run format:check`, `npm run knip`: pass. jscpd is 2.599% (threshold 2.6%). - `npm test`: 8,345 passed, 12 failed. These are the same 12 that fail on a clean origin/main worktree on this Mac: ibtool NIB tests, the hdiutil verify refusal, and JS runtime discovery paths under `/private/var`. - Not verified against real compiled .NET assemblies; none are on this machine. 🤖 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