[PR #3157] [CLOSED] fix(native): share the Swift mangling prefix owner with symbol projections #5646

Closed
opened 2026-10-31 01:08:15 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/3157
Author: @XiaoBinGan
Created: 10/14/2026
Status: ❌ Closed

Base: main ← Head: fix/swift-mangling-prefix-owner


📝 Commits (1)

  • 86e27f5 fix(native): share the Swift mangling prefix owner with symbol projections

📊 Changes

4 files changed (+54 additions, -18 deletions)

View changed files

📝 src/domain/native/objcSwiftMetadata.test.ts (+28 -0)
📝 src/domain/native/objcSwiftMetadata.ts (+2 -1)
📝 src/domain/swiftSymbolClassification.ts (+21 -0)
📝 src/native/parsers/demangle.ts (+3 -17)

📄 Description

Summary

The Objective-C/Swift metadata projection dropped Swift symbols whose mangled names use a prefix other than $s/_$s, and its coverage facet counted only what the narrow pattern had already matched, so the loss of supplied inventory symbols was invisible to consumers.

Problem and expected behavior

inspectNativeDispatchMetadata asks "is this symbol name a Swift mangling?" and answered it with a second, private pattern:

if (/^(?:_?\$s|_Tt)/u.test(entry.name))

The Swift demangler accepts more prefixes than that. Running the tool over a symbol inventory of ten Swift manglings on current main reports three:

input reported before
$s5Store7launchyyF yes
_$s5Store7launchyyF yes
_TtC5Store11StoreHandle yes
$S5Store7launchyyF, _$S5Store7launchyyF (Swift 4.1+) dropped
_T05Store7launchyyF (Swift 4) dropped
@__swiftmacro_5Store7launchfMf_ dropped
$e5Store7launchyyF, _$e5Store7launchyyF (Embedded Swift) dropped

The swift_declarations coverage facet then reported examined: 3 for that inventory. Because the count is derived from the same narrowed projection, an unread symbol is not merely omitted — it is never counted as supplied evidence, so a consumer cannot distinguish "this binary has three Swift symbols" from "the projection recognized three of ten". #3080's sibling change for demangle_swift (#3089) already established the full accepted prefix set for the same question inside src/native/parsers/demangle.ts.

Expected: one owner for "which names the Swift demangler accepts as manglings", used by both the demangle parser and the metadata projection, so the projection neither drops accepted prefixes nor hides the count.

Change and scope

  • src/domain/swiftSymbolClassification.ts — owns the prefix set and exports isSwiftMangledSymbolName. This module already owns "recognize Swift manglings"; the list moves to the domain layer so that the provider adapter can depend inward rather than the domain reaching into src/native/.
  • src/native/parsers/demangle.ts — imports the owner and drops its private copy of the list. Behavior is unchanged.
  • src/domain/native/objcSwiftMetadata.ts — uses the owner instead of reinterpretating raw symbol names. Objective-C visible Swift class names (_Tt…) are not demangler manglings, so that spelling remains an explicit part of this projection's own predicate.
  • src/domain/native/objcSwiftMetadata.test.ts — regression test.

No command, option, schema, or declared contract changes. swift_symbols stays an additive, partial-decoded projection.

Contract and boundary impact

The projection now preserves symbols it previously discarded, and swift_declarations.examined counts every recognized Swift symbol in the examined inventory instead of only the ones matching one pattern. Both remain partial with the existing symbols_are_not_demangled_declarations reason, so no decode status is upgraded and no symbol is asserted to be a valid declaration. classifySwiftSymbol keeps its own _?(\$[sS]|_T0) pattern deliberately: it selects which prefixes can carry the nominal category encoding it decodes, which is a different question from which prefixes the demangler accepts.

Evidence and regression coverage

npm run test:focused -- src/domain/native/objcSwiftMetadata.test.ts src/native/parsers/demangle.test.ts tests/boundary/mcp/nativeDemangleMcp.test.ts → 3 files, 11 tests passed.

The new test asserts all nine accepted prefixes are reported in input order and that the coverage facet counts nine, with _Tprintf retained as the ordinary-C-spelling control. Before the change the same test fails with the three symbols the old pattern recognized; src/domain/native/objcSwiftMetadata.ts is byte-identical between the commit used for that before-run and current main.

npm run check:fast → 2 successful. npm run format:check → clean. npm run deps:check → clean.

Unavailable coverage

Symbol names are supplied by the caller, so this change is exercised through the source projection rather than a real Swift binary; no provider, demangler, or target execution was involved. The prefixes are taken from the set #3089 established for swift-demangle, and this change does not add independent toolchain verification of which prefixes a given swift-demangle build accepts.


🔄 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/3157 **Author:** [@XiaoBinGan](https://github.com/XiaoBinGan) **Created:** 10/14/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/swift-mangling-prefix-owner` --- ### 📝 Commits (1) - [`86e27f5`](https://github.com/morluto/rea/commit/86e27f59f1e7f9151728898b1d8e64220089fd16) fix(native): share the Swift mangling prefix owner with symbol projections ### 📊 Changes **4 files changed** (+54 additions, -18 deletions) <details> <summary>View changed files</summary> 📝 `src/domain/native/objcSwiftMetadata.test.ts` (+28 -0) 📝 `src/domain/native/objcSwiftMetadata.ts` (+2 -1) 📝 `src/domain/swiftSymbolClassification.ts` (+21 -0) 📝 `src/native/parsers/demangle.ts` (+3 -17) </details> ### 📄 Description ## Summary The Objective-C/Swift metadata projection dropped Swift symbols whose mangled names use a prefix other than `$s`/`_$s`, and its coverage facet counted only what the narrow pattern had already matched, so the loss of supplied inventory symbols was invisible to consumers. ## Problem and expected behavior `inspectNativeDispatchMetadata` asks "is this symbol name a Swift mangling?" and answered it with a second, private pattern: ```ts if (/^(?:_?\$s|_Tt)/u.test(entry.name)) ``` The Swift demangler accepts more prefixes than that. Running the tool over a symbol inventory of ten Swift manglings on current `main` reports three: | input | reported before | |---|---| | `$s5Store7launchyyF` | yes | | `_$s5Store7launchyyF` | yes | | `_TtC5Store11StoreHandle` | yes | | `$S5Store7launchyyF`, `_$S5Store7launchyyF` (Swift 4.1+) | **dropped** | | `_T05Store7launchyyF` (Swift 4) | **dropped** | | `@__swiftmacro_5Store7launchfMf_` | **dropped** | | `$e5Store7launchyyF`, `_$e5Store7launchyyF` (Embedded Swift) | **dropped** | The `swift_declarations` coverage facet then reported `examined: 3` for that inventory. Because the count is derived from the same narrowed projection, an unread symbol is not merely omitted — it is never counted as supplied evidence, so a consumer cannot distinguish "this binary has three Swift symbols" from "the projection recognized three of ten". `#3080`'s sibling change for `demangle_swift` (`#3089`) already established the full accepted prefix set for the same question inside `src/native/parsers/demangle.ts`. Expected: one owner for "which names the Swift demangler accepts as manglings", used by both the demangle parser and the metadata projection, so the projection neither drops accepted prefixes nor hides the count. ## Change and scope - `src/domain/swiftSymbolClassification.ts` — owns the prefix set and exports `isSwiftMangledSymbolName`. This module already owns "recognize Swift manglings"; the list moves to the domain layer so that the provider adapter can depend inward rather than the domain reaching into `src/native/`. - `src/native/parsers/demangle.ts` — imports the owner and drops its private copy of the list. Behavior is unchanged. - `src/domain/native/objcSwiftMetadata.ts` — uses the owner instead of reinterpretating raw symbol names. Objective-C visible Swift class names (`_Tt…`) are not demangler manglings, so that spelling remains an explicit part of this projection's own predicate. - `src/domain/native/objcSwiftMetadata.test.ts` — regression test. No command, option, schema, or declared contract changes. `swift_symbols` stays an additive, `partial`-decoded projection. ## Contract and boundary impact The projection now preserves symbols it previously discarded, and `swift_declarations.examined` counts every recognized Swift symbol in the examined inventory instead of only the ones matching one pattern. Both remain `partial` with the existing `symbols_are_not_demangled_declarations` reason, so no decode status is upgraded and no symbol is asserted to be a valid declaration. `classifySwiftSymbol` keeps its own `_?(\$[sS]|_T0)` pattern deliberately: it selects which prefixes can carry the nominal category encoding it decodes, which is a different question from which prefixes the demangler accepts. ## Evidence and regression coverage `npm run test:focused -- src/domain/native/objcSwiftMetadata.test.ts src/native/parsers/demangle.test.ts tests/boundary/mcp/nativeDemangleMcp.test.ts` → 3 files, 11 tests passed. The new test asserts all nine accepted prefixes are reported in input order and that the coverage facet counts nine, with `_Tprintf` retained as the ordinary-C-spelling control. Before the change the same test fails with the three symbols the old pattern recognized; `src/domain/native/objcSwiftMetadata.ts` is byte-identical between the commit used for that before-run and current `main`. `npm run check:fast` → 2 successful. `npm run format:check` → clean. `npm run deps:check` → clean. ## Unavailable coverage Symbol names are supplied by the caller, so this change is exercised through the source projection rather than a real Swift binary; no provider, demangler, or target execution was involved. The prefixes are taken from the set `#3089` established for `swift-demangle`, and this change does not add independent toolchain verification of which prefixes a given `swift-demangle` build accepts. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-10-31 01:08:15 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#5646
No description provided.