code-review-graph 的 Julia 解析器对账实现从 PR #560 移植到无冲突身份与最近作用域调用解析【免费下载链接】code-review-graphLocal-first code intelligence graph for MCP and CLI. Builds a persistent map of your codebase so AI coding tools read only what matters, with benchmarked context reductions on reviews and large-repo workflows.项目地址: https://gitcode.com/GitHub_Trending/co/code-review-graph导读code-review-graph 是一个本地优先的代码智能图谱工具为 MCP 与 CLI 场景构建代码库的持久化调用关系图。本文以仓库中docs/superpowers/plans/2026-07-17-julia-parser-reconciliation.md这份实现计划为核心完整讲解 Julia 解析器对账reconciliation工程的背景、设计与落地步骤如何在保持既有图 schema 与多语言通用行为不变的前提下从过期的 PR #560 中安全移植 Julia 解析能力并为嵌套、模块限定qualified定义建立无冲突规范身份、实现从最近词法作用域向外的调用解析。读完本文你将掌握该计划的任务拆解、关键 AST 辅助函数契约、测试驱动流程与质量门禁并能在当前仓库中复现全部验证步骤。一、背景为什么需要对账 PR #5601.1 现状main 分支已具备的基础能力按照设计文档docs/superpowers/specs/2026-07-17-julia-parser-reconciliation-design.md的陈述当前main分支的 Julia 解析已经覆盖模块module与结构体struct长形式function f(x) ... end与短形式f(x) ...函数import、include、export/public符号宏macro、枚举enum、testset。这一点可以从 sample.jl 中得到印证该夹具文件同时包含enum Color RED BLUE GREEN、abstract type、struct、function Base.show(io, d::Dog)、const MY_CONST 42、macro sayhello、嵌套inner()、include(utils.jl)以及testset Arithmetic等典型构造。1.2 缺口源 PR #560 的局限PR #560 为 Julia 增加了有用的覆盖但其 headf66721a6f63cc352ea515ddf9ca6e9cba21c4666已经过期并与当前main冲突。更重要的是源实现存在三方面结构性缺陷限定符只存在extra中模块限定符仅作为展示元数据存储不参与图身份identity与调用目标计算。结果是本地show会与Base.show发生身份碰撞限定调用可能被折叠成裸的show下游图查询无法区分二者。嵌套作用域丢失当前嵌套 Julia 模块与函数会丢失外层词法作用域持久化后无法还原完整的Outer.Inner.f路径。限定调用目标不完整多段限定的点号调用目标无法保留完整路径。1.3 对账目标与非目标目标移植 PR #560 中安全、不重叠的 Julia 行为为限定定义提供无冲突的规范身份将裸调用与限定调用解析到最近的匹配词法符号通过持久化保留完整的嵌套模块/函数作用域为别名导入记录真实模块并让经别名调用的调用规范化到真实路径对畸形或不支持的 Julia 语法保持 fail-soft不产生虚假节点保留既有的宏、枚举、testset、导出、include 与全部 Julia 测试。非目标不替换 Julia 解析器、不改动图 schema不建模 Julia 基于参数类型的多重分派不为普通标量const绑定创建节点不为文件内不存在的模块凭空发明定义不支持捆绑语法只能产出ERROR节点的畸形限定函数 stub不对源 PR #560 做合并、关闭、重开或评论操作。二、实现计划总览文件结构与执行模型2.1 文件级变更动作文件作用新建tests/test_julia_reconciliation.py独立于共享多语言夹具的 Julia 专项回归测试解析、作用域、fail-soft、持久化与下游查询修改code_review_graph/parser.pyJulia 专用辅助函数与提取、作用域、导入别名、调用目标与同文件解析行为保持不动tests/fixtures/sample.jl、tests/test_multilang.py作为既有 Julia 行为的独立无回归检查计划文档给出的关键源码区间包括code_review_graph/parser.py:3361-3695Julia 构造提取相关、7431-7475、7909-7950Task 1、2423-2460,4889-5225,5257-5360Task 2、3630-3695,4889-5020,6707-6760Task 3。2.2 执行模型可见证的红-绿-重构计划文档要求实现遵循“可见证的红-绿-重构循环”先为每个行为编写聚焦的失败测试运行测试确认RED预期失败——源 PR #560 前的生产代码无法通过以最小实现让测试转GREEN在全部测试通过后才清理重复的 AST 遍历并重跑同一命令确认无回归。这与设计文档中“在专用 Julia 测试模块中进行可见证红绿循环”的八步测试序列一一对应函数 stub 与畸形限定 stub 的 fail-soft → 裸/引号/限定/多段操作符定义 → 参数化 const 别名 vs 标量常量 → 顶层与选中别名导入及别名限定调用 → 单行 RHS 调用 → 长短限定定义与本地名碰撞 → 嵌套模块/函数与最近作用域调用、宏、testset →full_build/GraphStore集成。三、Task 1Julia 叶子构造与 fail-soft 提取3.1 测试先行直接解析片段Task 1 的核心思路是不写生产文件、直接解析源码片段。测试辅助函数如下from pathlib import Path import pytest from code_review_graph.parser import CodeParser def _parse(source: str): return CodeParser().parse_bytes(Path(/repo/case.jl), source.encode())计划文档要求验证五类行为def test_function_stub_is_a_function(): nodes, _ _parse(function hook end) assert [(n.kind, n.name) for n in nodes if n.kind ! File] [ (Function, hook), ] pytest.mark.parametrize(signature, [(a, b) a, Base.:(a, b) a]) def test_operator_definition_uses_operator_name(signature): nodes, _ _parse(signature) functions [n for n in nodes if n.kind Function] assert [n.name for n in functions] [] def test_parameterized_const_only_is_a_type(): nodes, _ _parse( const FloatVec Vector{Float64}\nconst MAX_RETRIES 3\n ) assert {n.name for n in nodes if n.kind Type} {FloatVec} def test_import_alias_records_real_dependency(): _, edges _parse( import DataFrames as DF\nimport Tables: AbstractColumns as Columns\n ) assert {e.target for e in edges if e.kind IMPORTS_FROM} { DataFrames, Tables.AbstractColumns, } def test_malformed_qualified_stub_fails_soft(): nodes, edges _parse(function A.B.hook end) assert [n.kind for n in nodes] [File] assert edges []其中test_malformed_qualified_stub_fails_soft在当前实现上就已经通过充当守卫测试function A.B.hook end会被捆绑语法解析为ERROR节点而全局约束明确禁止从ERROR节点推断定义。在仓库的tests/test_julia_reconciliation.py中可以看到该契约被完整保留并扩充test_operator_definition_uses_operator_name增加了Base.:()(a, b) true参数化用例test_parameterized_const_only_is_a_type增加了const PairMap Dict{String, Tuple{Int, Int}}的多层参数化类型用例。3.2 验证 RED 的命令uv run --frozen --no-sync pytest -q \ tests/test_julia_reconciliation.py::test_function_stub_is_a_function \ tests/test_julia_reconciliation.py::test_operator_definition_uses_operator_name \ tests/test_julia_reconciliation.py::test_parameterized_const_only_is_a_type \ tests/test_julia_reconciliation.py::test_import_alias_records_real_dependency \ tests/test_julia_reconciliation.py::test_malformed_qualified_stub_fails_soft预期stub、操作符、类型别名、导入别名断言因缺少行为而失败畸形输入已通过并守卫实现。3.3 最小实现组件名、字段拆分与 const 分支计划的辅助函数契约是作用域无关的组件名提取器对未知形状一律返回Nonestaticmethod def _julia_component_name(node) - Optional[str]: if node.type in (identifier, operator): return node.text.decode(utf-8, errorsreplace) if node.type quote_expression: for child in node.children: name CodeParser._julia_component_name(child) if name is not None: return name if node.type parenthesized_expression: for child in node.children: if child.type operator: return child.text.decode(utf-8, errorsreplace) return None在 parser.py 的实际实现中该契约被保留并做了小范围合并quote_expression与parenthesized_expression走同一个递归分支。它与_julia_field_parts、_julia_field_info配合实现“展平嵌套field_expression→ 读取末尾标识符或引号操作符 → 拆分限定符与叶子名”的完整链路见parser.py:7389-7425。这些辅助函数被_julia_short_func_name与 Julia 的_get_name使用const_statement分支加入_extract_julia_constructs_extract_import扩展处理import_alias节点。参数化 const 的处理规则与parser.py:7611-7656的实现一致当const_statement内的assignment右值是parametrized_type_expression或curly_expression时追加NodeInfo(kindType, ...)并生成配套的CONTAINS边然后返回True表示该子节点已完全处理其他任何 const 语句都不消费留在通用路径上。要点标量const MAX_RETRIES 3不会成为 Type 节点只有const FloatVec Vector{Float64}这种参数化/花括号类型表达式才是类型声明。3.4 验证 GREENuv run --frozen --no-sync pytest -q \ tests/test_julia_reconciliation.py tests/test_multilang.py::TestJuliaParsing预期全部通过且不破坏既有 Julia 夹具断言。四、Task 2规范限定身份与作用域调用解析4.1 身份模型词法作用域拼接设计文档明确了身份规则——Julia 专有复用既有的NodeInfo.parent_name身份模型词法作用域拼接而非互相替换Outer.Inner中的函数f父级为Outer.Inner限定名为file.jl::Outer.Inner.f该函数内部的嵌套函数g父级为Outer.Inner.f限定名为file.jl::Outer.Inner.f.g在Outer.Inner内书写function Base.show父级为Outer.Inner.Base限定名为file.jl::Outer.Inner.Base.show。显式限定符仍保留在extra[julia_module_qualifier]供需要直接读取的消费者使用限定定义的CONTAINS边的源仍是其词法模块file.jl::Outer.Inner而不是合成的Base节点——这样既保留源码结构又让身份无碰撞。实现层面计划给出统一身份规则长、短形式通用lexical_parent self._julia_scope_join(enclosing_class, enclosing_func) identity_parent self._julia_scope_join(lexical_parent, qualifier)当qualifier缺失时identity_parent就等于lexical_parent。存储显式限定符到extra[julia_module_qualifier]CONTAINS边从lexical_parent出发递归进入函数体时使用enclosing_classidentity_parent、enclosing_funcname。_julia_scope_join的实现parser.py:7428-7438保证拼接不会重复已有前缀若inner等于outer或以outer.开头则直接返回inner。4.2 调用提取与解析_extract_calls侧Julia 字段表达式 callee 替换为其完整qualifier.leaf文本并设置julia_call_module短形式 RHS 调用节点在其子节点下探之前直接分发处理。这避免了把左值签名当作自调用重复访问。_resolve_call_targets侧Julia 专用parser.py:4939-5046非 Julia 文件保留原实现对 Julia把每个定义按规范限定名的尾段tail建立索引对源file::Outer.Inner.caller与目标f按如下顺序尝试候选Outer.Inner.caller.f、Outer.Inner.f、Outer.f、f对extra含julia_qualified_def的REFERENCES边跳过本地改写——防止文件中恰好存在名为Base的定义改变限定符引用的语义。源码实现中还有一处值得注意的细节qualified_boundaries机制。对带julia_module_qualifier的限定方法先把身份路径与词法父级配对并按身份路径长度倒序排序搜索作用域时若当前作用域命中某个限定方法边界则先在该方法体内由深到浅搜索然后跳出边界从该方法的词法父级继续向外搜索parser.py:4952-5008。这正是Base.show方法体内的裸helper()能解析到同模块的Demo.helper而非错误的Demo.Base.helper的原因对应测试test_qualified_method_body_uses_lexical_scope_for_bare_calls。4.3 验证用例碰撞与调用计划要求使用一个定义本地show、Base.show、Base.length、Base.:、A.B.run、单行委托与点号调用的模块断言精确身份与边assert (show, Demo) in identities assert (show, Demo.Base) in identities assert (length, Demo.Base) in identities assert (, Demo.Base) in identities assert (run, Demo.A.B) in identities assert (Demo.delegate, Demo.show) in call_tails assert (Demo.caller, Demo.A.B.run) in call_tails assert any( e.target LinearAlgebra.BLAS.gemv and e.extra[julia_call_module] LinearAlgebra.BLAS for e in calls )同时断言Demo.Base.show的限定符引用指向字面量Base——即使文件中存在名为Base的本地函数。这条在仓库测试test_qualified_definitions_have_collision_free_identities中被完整落地且额外验证了function Base() end产生的(Base, Demo)身份与限定方法身份互不干扰。RED 阶段预期限定身份在Demo下折叠、Base.:变成虚假的Base函数、单行调用缺失、点号目标停留在裸叶子。五、Task 3嵌套作用域、别名、宏与 testset5.1 嵌套模块与函数的完整词法路径对 Julia class/module 提取递归时使用拼接后的作用域CONTAINS边从包围作用域而非总是从 File出发。testset 使用拼接的函数词法作用域作为parent_name、包含源与递归作用域。仓库测试test_nested_modules_and_functions_keep_complete_scope验证了Outer.Inner结构(Inner, Outer)、(f, Outer.Inner)、(wrapper, Outer.Inner)、(leaf, Outer.Inner.wrapper)全部成立且Outer.Inner.wrapper.leaf对f(y)的调用解析到Outer.Inner.f最近作用域优先而非外层Outer.f。计划中的断言assert Outer.Inner in class_parents_and_names assert (f, Outer.Inner) in identities assert (leaf, Outer.Inner.wrapper) in identities assert any(e.target.endswith(::Outer.Inner.f) for e in calls_from_inner) assert any(n.kind Test and n.parent_name Outer.Inner.wrapper for n in nodes) assert any(e.target DataFrames.transform for e in alias_calls) assert any(e.target inline for e in calls)仓库测试test_function_local_testset_and_macros_keep_canonical_scope进一步确认函数内testset nested的parent_name为Demo.wrappertestset 内test subject(x) x的调用边源是该 testset 的规范限定名、目标是Demo.subjectinline subject(x)则产生以inline为目标保持宏形态不做符号重写的CALLS边。5.2 导入别名规范化扩展_collect_import_names以处理 Julia 别名import_map[DF] DataFrames import_map[Columns] Tables.AbstractColumns当限定调用的首个模块段是别名时在形成最终点号目标前先替换为真实模块直接模块保持不变。实际实现_collect_julia_scoped_import_namesparser.py:13054-13087把别名键做作用域化处理key _julia_scope_join(current_scope, alias)从而避免别名跨模块泄漏。_resolve_julia_import_aliasparser.py:7518-7533则从最近的词法作用域向外逐级查找prefix.alias键。仓库测试test_calls_through_import_aliases_use_real_module_paths覆盖了三种情形Demo内import DataFrames as DF后DF.transform(x)→ 目标DataFrames.transformjulia_call_module DataFramesimport Tables: AbstractColumns as Columns后Columns(x)→ 目标Tables.AbstractColumns选中导入保留多段符号路径Other模块内import OtherFrames as DF后DF.transform(x)→ 目标OtherFrames.transform——同一别名DF在不同模块中互不串扰。test_selected_import_alias_keeps_multi_segment_module_path则验证import Foo.Bar: thing as alias后alias()解析到Foo.Bar.thing。5.3 枚举与 wrapped 签名任务 3 区间之外还有两个值得一提的关联行为同样被专项测试覆盖test_enum_variants_use_the_full_lexical_type_parentenum Color RED的变体RED的父级是Demo.Color完整词法类型父级CONTAINS源也是Demo.Colortest_wrapped_qualified_signature_is_not_a_self_callfunction A.B.f(x)::Int where {T}这种被where_expression/typed_expression包裹的签名不会被误判为自调用_julia_signature_call做有界遍历在 signature 内最多下钻 4 层查找call_expression见parser.py:7440-7474test_wrapped_signature_keeps_evaluated_return_type_callfunction f(x)::g()保留对g的调用边同时排除虚假的f自调用。六、Task 4GraphStore 与下游查询持久化6.1 集成回归测试Task 4 的接口是full_build(Path, GraphStore) - dict来自 incremental.py仓库测试从code_review_graph.incremental导入与规范解析输出。计划要求创建.git与 Julia 源文件后执行全量构建local store.get_node(f{source_path}::Demo.show) base store.get_node(f{source_path}::Demo.Base.show) assert local is not None and base is not None and local.id ! base.id callers store.get_edges_by_target(f{source_path}::Demo.Base.show) assert any(edge.kind CALLS and edge.source.endswith(::Demo.invoke) for edge in callers) assert result[errors] []还要查询持久化的嵌套目标与 Type 别名并在finally中关闭 store。仓库落地版本test_full_build_persists_distinct_qualified_nodes_and_callerstests/test_julia_reconciliation.py:453-491与此一致并额外断言base_node.extra[julia_module_qualifier] Base、Demo.FloatVecType 别名节点存在、调用者边通过edge.source_qualified匹配Demo.invoke。这里用到的是 graph.py 中GraphStore.get_nodegraph.py:424与get_edges_by_targetgraph.py:470这两个下游 API。6.2 验证策略与全量回归基线Step 2 要求先对移植前的生产代码跑该测试必须失败若 Task 1–3 已使其通过则临时回退 parser 改动确认预期失败再恢复并重跑绿色Step 3 命令uv run --frozen --no-sync pytest -q tests/test_julia_reconciliation.py \ tests/test_multilang.py::TestJuliaParsing uv run --frozen --no-sync pytest -q基线断言全量 1,573 个既有通过用例保持绿色加上新增 Julia 测试既有 skip/xpass 保持非失败状态。七、Task 5静态检查、图谱审查、署名与发布7.1 本地质量门禁uv run --frozen --no-sync ruff check code_review_graph tests uv run --frozen --no-sync ruff format --check code_review_graph tests uv run --frozen --no-sync mypy code_review_graph uv run --frozen --no-sync bandit -q -r code_review_graph uv run --frozen --no-sync python scripts/check_schema_sync.py git diff --check预期每条命令退出码为 0。7.2 图谱与差异审查增量重建知识图谱后针对origin/main运行变更检测change detection、受影响 flowaffected flows、tests-for 查询与聚焦评审上下文。检查git diff --stat与git diff确保只有获批的文件与行为发生变化。7.3 提交署名、变基与 PR提交生产代码与测试时携带 trailerCo-authored-by: dan danvincifastmail.net之后 fetchorigin/main、变基分支、重跑聚焦/全量测试与全部静态检查、更新图谱、检查最终 diff。不允许引入无关变更未经明确批准不得强制推送。最后推送并打开替代 PRPR 正文必须点名源 PR #560 及其确切 head、枚举重叠与移植行为、说明额外的碰撞/调用解析阻塞原因、陈述确切 base/head 与本地测试证据、署名 Dan并声明源 PR #560 未被修改。要等包括 Windows 在内的所有必需检查通过后才报告就绪。八、关键机制速查辅助函数契约与身份规则设计文档将 AST 辅助函数归纳为六个职责全部是 Julia 专有且不影响通用语言行为按源码顺序展平嵌套field_expression节点_julia_field_parts读取末尾标识符或引号操作符组件_julia_component_name把字段拆分为限定符与叶子名_julia_field_info在where_expression/typed_expression等签名包装内用有界遍历寻找可调用目标_julia_signature_call/_julia_signature_callee拼接词法作用域且不重复路径段_julia_scope_join从import_alias节点读取导入别名_collect_import_names_resolve_julia_import_alias。约束每个辅助函数对未知形状返回None或空结果不检查子节点就不做索引绝不从 Tree-sitterERROR节点恢复定义。这些约束保证了 fail-soft 特性也让function A.B.hook end这类畸形语法只留下File节点与零条边。身份规则汇总Julia 专用复用既有parent_name模型源码写法parent_name限定名Outer.Inner内function fOuter.Innerfile.jl::Outer.Inner.fOuter.Inner.f内嵌套function gOuter.Inner.ffile.jl::Outer.Inner.f.gOuter.Inner内function Base.showOuter.Inner.Basefile.jl::Outer.Inner.Base.showconst FloatVec Vector{Float64}所在词法作用域Type 节点 对应CONTAINS边(a,b) a/Base.:(a,b) a无 /Base函数名统一为九、与既有 Julia 测试的关系无回归保障计划文档明确要求tests/fixtures/sample.jl与tests/test_multilang.py::TestJuliaParsing保持不动作为既有 Julia 行为的独立无回归检查。每一步 GREEN 验证都同时运行该夹具类。设计文档也强调现有 Julia 夹具测试在每轮聚焦循环之后运行最终验证包含完整测试套件、Ruff、类型/schema/安全检查CI 所用、diff 审查、图谱变更/flow 审查以及包括 Windows 在内的全部 GitHub 检查。这意味着对账工程不是推倒重来而是在既有解析能力之上做增量补齐stub、操作符、参数化 const 别名、别名导入、单行调用体与完整模块限定符正是设计文档列出的“剩余源码行为”清单。十、可复现验证清单在仓库根目录按序执行以下命令即可复现整个对账工程的关键验证# Task 1 聚焦失败测试RED 阶段 uv run --frozen --no-sync pytest -q \ tests/test_julia_reconciliation.py::test_function_stub_is_a_function \ tests/test_julia_reconciliation.py::test_operator_definition_uses_operator_name \ tests/test_julia_reconciliation.py::test_parameterized_const_only_is_a_type \ tests/test_julia_reconciliation.py::test_import_alias_records_real_dependency \ tests/test_julia_reconciliation.py::test_malformed_qualified_stub_fails_soft # 每个 Task 的 GREEN 既有夹具无回归 uv run --frozen --no-sync pytest -q \ tests/test_julia_reconciliation.py tests/test_multilang.py::TestJuliaParsing # Task 4 全量回归基线 1,573 通过 新增 uv run --frozen --no-sync pytest -q # Task 5 静态质量门禁 uv run --frozen --no-sync ruff check code_review_graph tests uv run --frozen --no-sync ruff format --check code_review_graph tests uv run --frozen --no-sync mypy code_review_graph uv run --frozen --no-sync bandit -q -r code_review_graph uv run --frozen --no-sync python scripts/check_schema_sync.py git diff --check结语Julia 解析器对账工程展示了 code-review-graph 维护多语言解析能力时的一条可复制路径以“不改 schema、不动通用行为、fail-soft、无回归、署名移植”为全局约束用可见证的红-绿-重构循环逐步移植外部 PR 的安全行为再以规范身份模型与最近作用域解析器补齐图质量的核心短板。最终产物是Demo.show与Demo.Base.show拥有互不碰撞的持久化身份Outer.Inner.wrapper.leaf内的裸调用解析到最近的Outer.Inner.f别名导入的调用落到真实模块路径而function A.B.hook end这类畸形输入依旧安静地不产生任何虚假节点。对于想要在自家解析器中对账语言覆盖的开发者docs/superpowers/plans/2026-07-17-julia-parser-reconciliation.md、配套设计文档与tests/test_julia_reconciliation.py三者合起来就是一份可以直接照做的工程模板。深入阅读实现计划 · 设计文档 · 专项回归测试 · Julia 夹具 · 解析器实现 · 图谱存储【免费下载链接】code-review-graphLocal-first code intelligence graph for MCP and CLI. Builds a persistent map of your codebase so AI coding tools read only what matters, with benchmarked context reductions on reviews and large-repo workflows.项目地址: https://gitcode.com/GitHub_Trending/co/code-review-graph创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考