Member walks silently drop unrecognized declarations (nested types, typealiases, indexed subscripts)
まだ誰も着手していません。
評価
調査の方向性
Interpreter+Structs.swiftから始め、続いてクラス、enum、extensionで共有されているメンバー走査を調べます。それらの既知の宣言分岐を#14のrejectMacroMemberパターンと比較し、ネストした型とインデックス付きsubscriptの再現コードを実行します。完了の条件は、現在サポートされていないすべてのメンバー宣言が、暗黙に消えるのではなく、宣言箇所で明確なRuntimeErrorを発生させて失敗することです。
索引モデルが issue の本文から書いたものです。
説明
Found while implementing #14. The struct / class / enum / extension member walks match the declaration kinds they know (var, init, func, subscript(dynamicMember:)) with an if / else-if chain that has no final else — every other member declaration is dropped without a sound, and the failure surfaces later as a misleading downstream error.
Reproduction (current main):
struct Outer {
struct Inner { var x: Int }
typealias ID = Int
}
let i = Outer.Inner(x: 1)
print(i.x)
error: type 'Outer' has no member 'Inner'
The declaration loaded fine — the nested struct Inner and the typealias ID were both silently discarded — and the error the user gets points at the use site with a claim that contradicts the source they can see. That is exactly the plausible-wrong-behavior class the issue #8 work (loud divergences) and the attribute preflight exist to prevent: a boundary error at the declaration would say "the interpreter can't do this yet"; the current error says "your code is wrong" when it isn't.
Silently dropped today (verified against the walk in Interpreter+Structs.swift; the class/enum/extension walks share the shape):
- nested type declarations (
struct,class,enum,actorinside a type) typealiasmembers- indexed subscripts — the
subscriptDeclbranch keeps only thesubscript(dynamicMember:)shape and silently ignoressubscript(_ i: Int)(declaring one succeeds; using it then fails confusingly) protocoldeclarations nested in a type
Freestanding macros in member position (struct S { #foo(\"x\") }) were on this list too; the #14 PR makes that one loud (rejectMacroMember), and its pattern is the suggested fix here: keep the walks' known branches, add a final else that throws RuntimeError.unsupported("declaration \(decl.syntaxNodeType) in member position", at: …) so unhandled member kinds fail at the declaration with an honest boundary message. Nested-type support can then be added later, kind by kind, without users ever passing through the misleading state.
- 主要言語
- Swift
- スター
- 76
- フォーク
- 8
- 平均マージ
- 25分
- マージ済み PR（30日）
- 1
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
Cocoanetics/SwiftScript のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
Cocoanetics/SwiftScript#22 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
Cocoanetics/SwiftScript#20 ·
Cocoanetics/SwiftScript の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
manaflow-ai/cmux#25687 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
kennss/SiliconScope#87 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
mozilla-mobile/firefox-ios#36314 ·
メンテナーはふだん 1 日以内に返信
-
documentation ready
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 76/100
sarensw/MacPacker#378 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信