ReScript reanalyze 死代码分析架构深度解析：从四阶段纯管道到响应式增量流水线

编译器编程语言开发工具【免费下载链接】rescript-compilerReScript is a robustly typed language that compiles to efficient and human-readable JavaScript.项目地址https://gitcode.com/gh_mirrors/re/rescript-compiler点击查看免费下载本文以 analysis/reanalyze/ARCHITECTURE.md 为核心骨架结合 analysis/reanalyze 与 analysis/reactive 的源码实现完整剖析 ReScript 官方死代码分析工具reanalyze的管道化架构。你将理解其 MAP→MERGE→SOLVE→REPORT 四阶段纯管道设计、前向不动点fixpoint活性分析算法、两遍可选参数分析以及基于响应式集合Reactive Collections实现的增量式分析流水线与 glitch-free 调度语义并能直接运用-reactive、-timing、-mermaid、-test-shuffle等标志复现文档中的架构视图与性能特性。总览四阶段纯管道设计reanalyze 的死代码消除DCE分析被刻意设计为一条纯管道pure pipeline共分四个阶段MAP独立处理每一个.cmt文件 → 产出每文件数据per-file dataMERGE合并所有每文件数据 → 得到不可变的项目级视图project-wide viewSOLVE计算死代码/存活状态 → 得到携带问题列表issues的不可变结果REPORT输出问题唯一的副作用发生地源码出处analysis/reanalyze/src/reanalyze.ml 中的run_analysis函数正是按这四个阶段组织process_cmt_filesMAP→Merging计时段MERGE→Solving计时段SOLVE→Reporting计时段REPORT。这一设计带来的四项核心能力顺序无关性Order independence无论以何种顺序处理文件最终结果完全一致增量更新Incremental updates替换某一个文件的数据而无需重新处理其他文件可测试性Testability每个阶段都是纯函数可独立构造输入、独立验证输出并行化潜力Parallelization potential阶段 1–3 均基于不可变数据天然支持并行执行。上述设计动机在 DEADCODE_REFACTOR_PLAN.md 中被进一步阐明重构前旧架构因全局可变状态导致无法增量分析、测试困难、无法并行、推理困难依赖顺序的隐式变更四大问题而纯管道重构的目标正是分析是输入→结果的纯函数、消除全局可变状态、副作用只存在于边缘、不同处理顺序结果相同、增量分析成为可能。下图来自文档附图展示了批处理模式下的完整管道对应 Mermaid 源文件为 batch-pipeline.mmd可用于自行修改与重新渲染。关键数据结构不可变数据模型管道各阶段之间通过不可变数据类型传递数据。文档给出的核心类型表如下类型用途可变性DceFileProcessing.file_data每文件采集到的数据BuildersAST 遍历期间可变FileAnnotations.t源码注解dead、live合并后不可变Declarations.t所有导出的声明pos →Decl.t合并后不可变References.t值/类型引用source → targets合并后不可变FileDeps.t跨文件依赖file →FileSet.t合并后不可变OptionalArgsState.t计算得到的每声明可选参数状态不可变AnalysisResult.t求解器输出内含Issue.t列表不可变DceConfig.t分析配置不可变显式传递从 dce_file_processing.ml 的源码可以看到file_data的实际定义它携带五个 builder等待下游合并type file_data { annotations: File_annotations.builder; (* dead / live 注解 *) decls: Declarations.builder; (* 导出的值/类型/异常声明 *) refs: References.builder; (* 对其他声明的引用 *) cross_file: Cross_file_items.builder; (* 需要跨文件解析的条目可选参数、异常 *) file_deps: File_deps.builder; (* 本文件依赖了哪些文件 *) }这种Builder可变仅在 MAP 阶段使用→ 不可变类型MERGE 之后使用的分界是局部可变、全局不可变原则的直接体现。Phase 1MAP —— 每文件独立处理入口函数DceFileProcessing.process_cmt_fileanalysis/reanalyze/src/dce_file_processing.ml输入.cmt文件路径 DceConfig.t输出包含以下 builder 的file_dataannotations—— 来自源码的dead、live注解decls—— 导出的值/类型/异常声明refs—— 对其他声明的引用file_deps—— 该文件依赖了哪些文件cross_file—— 需要跨文件解析的条目可选参数、异常。关键性质此阶段允许局部可变状态出于性能考虑每个文件被完全独立地处理。process_cmt_file会依据cmt_infos.cmt_annots区分接口Interface与实现Implementation接口直接处理签名实现则先检查是否存在对应的.cmti文件影响genType注解的采集策略再依次执行Collect_annotations.structure、process_signature与Dead_value.process_structure完成三类信息的收集。在管道编排层reanalyze.ml 的load_cmt_file先通过Cmt_format.read_cmt读取编译产物再依据exclude_paths前缀过滤、判定接口/实现与模块名最后分发到 DCEprocess_cmt_file、异常分析Exception.process_cmt与终止性分析Arnold.process_cmt三条支线process_cmt_files则负责收集全部.cmt/.cmti路径自动跳过node_modules、_esy目录或读取 rewatch 生成的.sourcedirs.json扫描计划以支持 monorepo。Phase 2MERGE —— 合并 builder 为项目级视图入口函数Reanalyze.runAnalysis的 merge 段analysis/reanalyze/src/reanalyze.ml输入file_data list输出不可变的项目级数据结构。核心操作文档原文let annotations FileAnnotations.merge_all (file_data_list | List.map (fun fd - fd.annotations)) let decls Declarations.merge_all (file_data_list | List.map (fun fd - fd.decls)) let refs References.merge_all (file_data_list | List.map (fun fd - fd.refs)) let file_deps FileDeps.merge_all (file_data_list | List.map (fun fd - fd.file_deps))关键性质所有合并操作都是可交换的commutative——file_data_list的顺序不影响合并结果这正是顺序无关性的底层保证。需要说明的是当前源码中该阶段的具体实现已演化为更精细的store体系见Reanalyze.runAnalysis的Merging计时段非响应式路径下调用Declarations.merge_all、File_annotations.merge_all、Cross_file_items.merge_all后分别包装进Declaration_store、Annotation_store、Cross_file_items_store引用图则通过References.create_buildermerge_into_builder增量累积再依次执行Dead_type.process_type_label_dependencies类型标签依赖解析与Cross_file_items.process_exception_refs跨文件异常引用解析最后References.freeze_builder冻结为不可变引用图并包装进Reference_store。可见文档中的四条merge_all是逻辑骨架而源码在保持同一合并冻结语义的前提下提供了更完整的实现细节。Phase 3SOLVE —— 死活性计算入口函数DeadCommon.solveDead非响应式以及Reanalyze.runAnalysis中的可选参数第二遍扫描响应式路径则为Reactive_solver.collect_issuesanalysis/reanalyze/src/reactive_solver.mli。输入全部合并后的数据 配置输出包含Issue.t list的AnalysisResult.t算法前向不动点 活性感知liveness-aware的可选参数分析。核心活性计算Liveness.compute_forward实现在 analysis/reanalyze/src/liveness.ml分三步识别根roots带有live/genType注解的声明或在任何声明之外被外部引用的声明is_root同时检查Annotation_store.is_annotated_gentype_or_live与externally_referenced表构建索引把每个声明映射到其出边引用refs_from方向。源码中build_decl_refs_index先按文件对声明分组再用pos_in_decl判断每条引用的posFrom落在哪个声明的区间内从而把表达式位置 → 目标的引用规约成声明 → 目标的声明级依赖图避免主循环中出现 O(worklist × refs) 的退化开销前向不动点从根出发沿引用不断传播活性直到工作队列为空返回全部存活位置集合。live_reason类型区分了三种存活原因便于-debug时诊断type live_reason | Annotated (* 带 live 或 genType 注解 *) | ExternalRef (* 在任意声明之外被引用 *) | Propagated (* 被其他存活声明引用 *)传播循环中还有一个重要细节若某个位置被注解为dead则不从它继续向外传播is_annotated_dead检查即死声明不会连累其下游。Pass 1死活性判定通过前向传播计算活性对每个声明检查是否在存活集合中标记死声明并收集问题。Pass 2活性感知的可选参数分析用 Pass 1 的结果构造is_live谓词源码中为Decl.is_live/Reactive_solver.is_pos_live通过CrossFileItems.compute_optional_args_state计算可选参数状态并过滤掉来自死代码的调用只对存活声明收集可选参数问题例如参数 X 从未被使用将可选参数问题合并进最终结果。这种两遍设计确保可选参数告警只统计存活代码中的调用避免当某函数仅被死代码调用时产生误报。关键性质纯函数 —— 不可变数据进、不可变数据出无副作用。在响应式路径中可选参数分析仍未完全接入响应式管道文档注明其仍走非响应式路径耗时约 8–14ms并留有 TODO把live_decls cross_file_items → optional_args_issues加入响应式流水线。Phase 4REPORT —— 边缘输出入口函数Reanalyze.runAnalysis的 report 段输入AnalysisResult.t输出日志 / JSON 到 stdout核心操作文档原文AnalysisResult.get_issues analysis_result | List.iter (fun issue - Log_.warning ~loc:issue.loc issue.description)关键性质所有副作用都集中在管道边缘。求解器从不直接打日志——Log_analysis/reanalyze/src/log_.ml是 REPORT 阶段专属的输出模块。若指定-json则由Emit_json输出结构化结果exception/termination分析的结果也在此阶段统一报告。增量更新的架构保证文档明确给出了文件变更 → 增量更新的标准路径仅对变更的文件重新执行 Phase 1 → 新的file_data在以文件名为键的file_data映射中替换该项重新执行 Phase 2合并—— 快速、纯函数重新执行 Phase 3求解—— 快速、纯函数。核心洞见不可变数据结构使得安全的增量更新成为可能——你可以只替换一个文件的数据而不会影响其他文件的数据。这也正是-reactive模式与 reanalyze-server 长驻服务得以成立的根本前提。响应式流水线Reactive Pipelines响应式层analysis/reactive提供基于 delta 的增量更新不再重跑整个阶段变更会通过派生的集合自动传播。核心响应式原语原语描述Reactive.t (k, v)通用响应式集合接口subscribe注册 delta 通知iter遍历当前条目get按键查找delta变更通知Set (k, v)、Remove k或Batch [(k, v option); ...]source创建带 emit 函数的可变源集合flatMap变换集合可选合并同键值join两个集合的哈希连接左连接语义union合并两个集合可选合并同键值fixpoint传递闭包init edges → reachableReactiveFileCollection带变更检测的文件支持集合这些接口在 analysis/reactive/src/reactive.mli 中均有完整签名其中delta类型定义为type (k, v) delta | Set of k * v | Remove of k | Batch of (k * v option) list (* (key, Some v) set(key, None) remove *)基于拓扑调度的 Glitch-Free 语义响应式系统采用accumulate-then-propagate先累积、后传播调度器实现glitch-free无毛刺传播保证派生集合始终看到一致的父状态。工作机制每个节点有一个level拓扑序源集合level 0派生集合level max(父节点 levels) 1每个组合子先把收到的 delta 累积到待处理缓冲pending buffers中调度器按 level 顺序访问脏节点并调用其process()每个节点在每一波wave中只处理一次且能拿到所有父节点的完整输入。典型排序示例文档原文file_collection (L0) → file_data (L1) → decls (L2) → live (L14) → dead_decls (L15)当一批文件变更到达时delta 先进入待处理缓冲不立即处理→ 调度器依次处理 level 0、level 1……→ 一个join只有在两个父节点都已更新后才会处理。这种设计从构造上消除了多层依赖带来的毛刺问题——analysis/reactive/test/glitch_free_test.ml 专门验证了反连接不会看到refs 已更新而 decls 未更新之类的部分状态。Reactive.Registry与Reactive.Scheduler模块还提供带统计追踪的命名节点用-timing查看统计to_mermaid()—— 生成管道图用-mermaid标志print_stats()—— 展示每节点耗时与 delta 计数。全响应式分析流水线响应式管道直接从源文件计算问题且在缓存命中时零重算文档原文图Files → file_data → decls, annotations, refs → live (fixpoint) → dead/live_decls → issues → REPORT ↓ ↓ ↓ ↓ ↓ ↓ ReactiveFile ReactiveMerge ReactiveLiveness ReactiveSolver iter Collection (flatMap) (fixpoint) (multiple joins) (only)关键性质当没有文件变更时不执行任何计算——所有响应式集合保持稳定只有最后的collect_issues调用迭代预计算好的集合O(issues)。文档给出的全响应式管道图约 25 个节点的高层视图Mermaid 源文件为 reactive-pipeline.mmd完整版44 个节点由-mermaid标志自动生成见 reactive-pipeline-full.mmd。README 还说明仓库检入的是-no-transitive变体因为跨文件hasRefBelow抑制在该模式下才生效响应式失效 bug 最容易在此暴露。流水线阶段阶段输入输出组合子文件处理.cmt文件file_dataReactiveFileCollection合并file_datadecls、annotations、refsflatMap活性refs、annotationslive位置集合fixpoint死/活划分decls、livedead_decls、live_declsjoin按活性划分死模块dead_decls、live_declsdead_modulesflatMapjoin反连接按文件分组dead_decls、refsdead_decls_by_file、refs_by_file带 merge 的flatMap按文件问题dead_decls_by_file、annotationsissues_by_fileflatMap排序过滤生成错误 deadlive_decls、annotationsincorrect_dead_declsjoin存活且带 dead 注解模块问题dead_modules、issues_by_filedead_module_issuesflatMapjoin报告所有问题集合stdoutiter仅迭代ReactiveSolver 集合集合类型描述dead_decls(pos, Decl.t)不在存活集合中的声明live_decls(pos, Decl.t)在存活集合中的声明dead_modules(Name.t, Location.t)仅含死声明的模块反连接dead_decls_by_file(file, Decl.t list)按文件分组的死声明value_refs_from_by_file(file, (pos, PosSet.t) list)按源文件分组的引用用于 hasRefBelowissues_by_file(file, Issue.t list * Name.t list)每文件问题 已报告的模块incorrect_dead_decls(pos, Decl.t)存活但带dead注解的声明dead_module_issues(Name.t, Issue.t)模块问题dead_modules 与 modules_with_reported 的连接注可选参数分析未使用/冗余参数尚未接入响应式管道仍走非响应式路径约 8–14ms。TODO将live_decls cross_file_items → optional_args_issues加入响应式流水线。Delta 传播当某个文件变更时ReactiveFileCollection检测到变更为file_data发出 deltaReactiveMerge收到 delta更新decls、refs、annotationsReactiveLiveness收到 delta通过增量不动点更新live集合ReactiveSolver收到 delta通过响应式 join 更新dead_decls和issues只有受影响的条目被重算——未触及的条目保持稳定。当没有任何文件变更时零计算——所有响应式集合保持稳定只有collect_issues迭代O(issues)——这是整条管道中唯一的迭代报告开销与问题数量呈线性关系。对应图示的 Mermaid/SVG 源见 delta-propagation.mmd 与 delta-propagation.svg。性能特征场景求解报告总计冷启动4900 个文件~2ms~3ms~7.7s缓存命中0 个文件变更~1-5ms~3-8ms~30ms单文件变更O(affected_decls)O(issues)极小关键洞见缓存命中时求解时间仅仅是迭代响应式issues集合的开销——没有 join 被重算没有不动点被重跑响应式集合保持稳定。需要说明的是上表数字来自文档自述的基准测量对应tests/analysis_tests/tests-reanalyze/deadcode-benchmark基准项目README 中亦有实测对比标准模式 CMT 处理 0.78s/总 1.01s而响应式热缓存CMT 处理 0.01s/总 0.20s约 5 倍总加速、74 倍 CMT 处理加速。数字会随机型与项目规模浮动建议以make benchmark、make time-cache、make time-reactive见 analysis/reanalyze/README.md自行复测。响应式模块划分模块职责Reactive核心原语source、flatMap、join、union、fixpoint、Scheduler、RegistryReactiveFileCollection带变更检测的文件支持集合ReactiveAnalysis带文件缓存的 CMT 处理ReactiveMerge从 file_data 派生 decls、annotations、refsReactiveTypeDeps类型标签依赖解析ReactiveExceptionRefs通过 join 解析异常引用ReactiveDeclRefs把声明映射到其出向引用ReactiveLiveness通过响应式不动点计算存活位置ReactiveSolver通过响应式 join 计算 dead_decls 与 issues各模块接口可分别查阅 reactive_merge.mli、reactive_liveness.mli、reactive_solver.mli 等响应式库本身的设计与用法见 analysis/reactive/README.md。统计追踪-timing使用-timing标志可查看每个节点的统计统计项描述d_recv收到的 delta 消息数Set/Remove/Batche_recv收到的条目数批量展开后in/-in从上游收到的增/删操作d_emit向下游发出的 delta 数e_emit发出的 delta 中的条目数out/-out发出的增/删操作非零-out表示 churn/抖动runs节点process()被调用的次数time_ms累计处理时间在Reanalyze.run_analysis_and_report中Reactive.set_debug !Cli.timing把调度器调试输出复用-timing开关避免与极冗长的-debug混淆并依次打印Reactive_liveness.print_stats、Reactive_solver.print_stats与全局Reactive.print_stats。-mermaid则将当前管道图以 Mermaid 文本输出到 stderr——README 给出了用它重新生成 reactive-pipeline-full.mmd 的完整命令# 在任意 ReScript 项目中运行-config 生效捕获 stderr rescript-tools reanalyze -config -reactive -no-transitive -mermaid \ /dev/null 2 analysis/reanalyze/diagrams/reactive-pipeline-full.mmd测试策略顺序无关性验证与分阶段单元测试顺序无关性测试使用仅用于测试的-test-shuffle标志随机化文件处理顺序。其实现位于 reanalyze.ml 的shuffle_listFisher–Yates 洗牌算法当Cli.test_shuffle为真时dce_data_list在合并前被随机重排从而验证结果不依赖遍历顺序。对应的端到端脚本 test-order-independence.sh 会先跑一次基线不洗牌再连续 3 次用-test-shuffle运行逐一diff输出任何不一致即失败。执行方式# 运行 reanalyze 相关测试 make test-reanalyze # 运行顺序无关性测试 make test-reanalyze-order-independence顶层 Makefile 中test-reanalyze委托给tests/analysis_tests/tests-reanalyze/deadcodetest-reanalyze-order-independence目标由 tests/analysis_tests/tests-reanalyze/Makefile 逐级下放。分阶段单元测试每个阶段可独立测试Phase 1处理单个.cmt文件验证file_dataPhase 2合并已知 builders验证合并结果Phase 3以已知输入调用求解器验证问题列表。响应式库自身的组合子测试见 analysis/reactive/testflat_map_test.ml、join_test.ml、union_test.ml、fixpoint_basic_test.ml、fixpoint_incremental_test.ml、batch_test.ml、glitch_free_test.ml、integration_test.ml分别覆盖各组合子、批量处理、无毛刺调度与端到端文件处理。关键模块总览模块职责Reanalyze入口编排整条管道reanalyze.mlDceFileProcessingPhase 1每文件 AST 处理dce_file_processing.mlDceConfig配置CLI 标志 运行配置DeadCommonPhase 3求解器solveDead、solveDeadReactivedead_common.mlLiveness前向不动点活性计算liveness.mlDeclarations声明存储builder/immutableReferences引用追踪source → targetsFileAnnotations源码注解追踪FileDeps跨文件依赖图CrossFileItems跨文件可选参数与异常AnalysisResult不可变的求解器输出Issue问题类型定义Log_Phase 4日志输出ReactiveSolver响应式 dead_decls → issues 计算reactive_solver.mli结语reanalyze 的架构精髓在于一条清晰的主线MAP/MERGE/SOLVE/REPORT 四阶段纯管道保证了顺序无关、可增量、可测试、可并行而响应式集合层则把增量更新从愿景落成实现——通过flatMap/join/union/fixpoint组合子、拓扑排序的 accumulate-then-propagate 调度器与不可变数据模型使得缓存命中时全管道零重算、单文件变更时只重算受影响条目。理解这套架构不仅可以直接上手rescript-tools reanalyze -config -reactive -timing -mermaid等命令观察管道运行也为在 ReScript 生态中设计增量分析工具如 reanalyze-server、编辑器集成提供了可复用的范式。赞分享编译器编程语言开发工具【免费下载链接】rescript-compilerReScript is a robustly typed language that compiles to efficient and human-readable JavaScript.项目地址https://gitcode.com/gh_mirrors/re/rescript-compiler点击查看免费下载相关推荐SQLFluff 架构深度解析从模板引擎到规则修复的四阶段流水线SQLFluff 架构深度解析从模板引擎到规则修复的四阶段流水线 SQLFluff 是一款模块化的 SQL 静态检查器linter与自动格式化工具支持多代码质量Lint格式化静态分析开发工具blink.cmp 架构深度解析Trigger → Sources → Fuzzy → Render 四阶段补全流水线blink.cmp 架构深度解析Trigger → Sources → Fuzzy → Render 四阶段补全流水线 导读 blink.cmp 是一个面向开发工具SQLFluff 架构解析从模板渲染到自动修复的四阶段流水线SQLFluff 架构解析从模板渲染到自动修复的四阶段流水线 SQLFluff 是一个模块化的 SQL 代码检查Linter与自动格式化Auto for代码质量Lint格式化静态分析开发工具上一篇Python Fire完全指南10分钟掌握自动化CLI生成神器下一篇TodoMVC测试框架揭秘如何确保45个实现版本的功能一致性创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考