feat(swift): add extension detection, inheritance edges, and type kind#202
Conversation
|
This PR is correct and well-implemented — the Swift extension name extraction, inheritance edges, and However, the branch now has merge conflicts with Once rebased, this is ready to merge. |
Three improvements to Swift language support: 1. Extension detection: extract name from user_type > type_identifier in _get_name() -- previously extensions were silently dropped because the name sat one level deeper than the generic path expected. 2. Inheritance/conformance edges: add Swift branch to _get_bases() that walks inheritance_specifier > user_type > type_identifier -- previously zero INHERITS edges were produced for Swift files. 3. Type differentiation: populate extra[swift_kind] with the actual keyword (class/struct/enum/actor/extension/protocol) following the same pattern as Solidity extra[solidity_kind]. Updated test fixture with enum, actor, and extension samples. Added 6 new tests covering all three fixes. All 621 existing tests pass with no regressions.
c07d9ce to
3d3cf01
Compare
|
Rebased onto latest |
15 new features: hub/bridge node detection, knowledge gap analysis, surprise scoring, suggested questions, BFS/DFS traversal, edge confidence scoring, export formats (GraphML/Neo4j/Obsidian/SVG), graph diff, token benchmarking, memory loop, community auto-splitting, 4 new languages (Zig/PowerShell/Julia/Svelte), visualization enhancements (degree-scaled nodes, community legend toggles). 6 community PRs merged: #127, #184, #202, #249, #253, #267. 28 MCP tools (was 22). Schema v9. 788 tests pass. README translations: zh-CN, ja-JP, ko-KR, hi-IN. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Summary
_get_name()to extract names fromuser_type > type_identifierfor Swift extensions — previously extensions were silently dropped because the name was nested one level deeper than the generic path expected._get_bases()that walksinheritance_specifier > user_type > type_identifier— previously zeroINHERITSedges were produced for any Swift file.extra["swift_kind"]with the actual keyword (class/struct/enum/actor/extension/protocol) following the same pattern as Solidity'sextra["solidity_kind"].Motivation
Swift's Tree-sitter grammar maps
struct,enum,actor, andextensiondeclarations all toclass_declarationnodes. The existing parser handled the first three correctly (sincetype_identifieris a direct child), but extensions useuser_type > type_identifierfor the extended type name, which was not traversed.Similarly, Swift uses
inheritance_specifier > user_type > type_identifierfor protocol conformances and class inheritance, but_get_bases()had no Swift-specific branch, resulting in zero inheritance edges.These gaps are significant for Swift projects using Clean Architecture (protocol-oriented design, extensions for conformance, actors for isolation).
Changes
parser.py:_get_name()user_typeparser.py:_get_bases()inheritance_specifiertraversalparser.py:_extract_classes()extra["swift_kind"]from keyword childtests/fixtures/sample.swiftenum,actor, andextensionsamplestests/test_multilang.pyTest plan
TestSwiftParsing)