Roc REPL 快照测试深度解析：以 List.keep_if 过滤测试为例-北京尧图网络

Roc REPL 快照测试深度解析以 List.keep_if 过滤测试为例【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc本文以 Roc 编译器仓库中的 REPL 快照测试文件 test/snapshots/repl/list_keep_if.md 为主体逐段解读其 META / SOURCE / OUTPUT / PROBLEMS 四段结构如何固化一条List.keep_if的求值行为并结合 test/snapshots/README.md 与同族快照用例说明这套快照测试在编译器回归验证中的定位、运行方式与调试手段。读完后你将能够独立阅读、运行并更新 Roc 编译器中任意一个 REPL 快照测试。快照文件的定位一条被固化的 REPL 求值记录该快照文件的核心内容非常简洁它只做一件事验证标准库列表方法List.keep_if在交互式 REPL 中的求值结果是否符合预期。文件按固定的四段结构组织段落内容作用METAdescriptionList.keep_if filters elements where predicate returns truetyperepl声明测试描述与测试类型REPL 求值快照SOURCE» List.keep_if([1, 2, 3, 4, 5], |x| x 2)固化的输入源»前缀表示 REPL 输入行OUTPUT[3.0, 4.0, 5.0]期望的求值输出PROBLEMSNIL期望的诊断信息NIL表示编译/求值过程未产生任何报告这种结构正是 Roc 编译器快照测试体系的统一格式。根据 test/snapshots/README.md 的说明快照测试通过捕获每个编译阶段的输出来验证编译器行为源码经过 tokenization、parsing、canonicalization、type checking 等阶段快照文件记录的是这些阶段的最终结果从而在编译器行为发生非预期变化时检测回归。测试用例本身keep_if 的谓词过滤语义SOURCE 段固化的表达式为» List.keep_if([1, 2, 3, 4, 5], |x| x 2)对应的期望输出是[3.0, 4.0, 5.0]这条用例验证的语义是keep_if只保留谓词返回 true 的元素。|x| x 2是 Roc 的箭头 lambda 写法对列表逐个元素判定最终1、2被过滤3、4、5被保留。两个细节值得注意输出的数值形态。期望输出写作[3.0, 4.0, 5.0]每个元素都带小数点说明在当前版本的 REPL 渲染下无注解的整数字面量列表被推断并按浮点数值类型展示。这一点可与同目录的 list_keep_if_try.md 对照其中[1.I64, 2, 3, 4].keep_if_try!(|n| Ok(n 2))显式标注了I64输出为Ok([3, 4])不带小数点——两种数值类型的渲染差异在快照输出中形成了天然的交叉印证。PROBLEMS 为NIL。按照 test/snapshots/README.md 的定义普通快照的PROBLEMS段存放每条reporting.Report的规范化 S 表达式序列化包含严重级别、标题、源码区域与完整文档结构不含渲染器相关的边框字符、ANSI 转义或换行NIL则意味着该次编译未产生任何报告。因此本文件同时固化了两件事求值结果正确且求值过程零诊断。在快照测试体系中的角色Roc 的快照测试分为两类本文件属于其中第一类普通快照typefile、snippet、expr以及本文件的typerepl捕获诊断的语义。PROBLEMS段是规范化 S 表达式回答编译器是否产生了正确的诊断。Reporting 快照typereporting位于reporting/目录固化渲染器输出。对同一个 SOURCE 分别渲染出REPORT、CLI、MARKDOWN、HTML、LSP五种用户可见格式布局、换行、标点与标记只在这里被固化。两者的分工保证了语义变更与呈现变更不会落在同一批文件里。README 还提到一条全局后处理规则快照后处理会把已移除的 header 关键字统一重写为mod该规则同样作用于 S 表达式输出内部。对list_keep_if.md这类PROBLEMS为NIL的用例而言后处理不产生影响但维护其他快照时需要知晓这一约定。运行与更新snapshot-tool 工具链快照的生成与更新通过 Zig 构建系统中的 snapshot-tool 完成其实现位于 src/snapshot_tool 目录。按 test/snapshots/README.md 给出的用法# 生成全部快照 zig build run-snapshot-tool # 只更新指定的一个快照文件 zig build run-snapshot-tool -- test/snapshots/repl/list_keep_if.md # 用当前 problems 输出反向更新期望 zig build run-snapshot-tool -- file_path --update-expected # 针对 REPL 快照开启求值追踪调试 zig build run-snapshot-tool -- test/snapshots/repl/list_keep_if.md --trace-eval其中--trace-eval有明确的使用前提仅对typerepl的快照有效本文件恰好属于此类一次只能传入单个快照文件调试构建中追踪默认启用发布构建需额外传-Dtrace-evaltrue。这套机制意味着当你修改了求值器、类型推断或标准库调用约定若List.keep_if的输出从[3.0, 4.0, 5.0]变为任何其他形态快照比对就会失败从而在 CI 中暴露回归。围绕 keep_if 的完整测试矩阵本文件并非孤立存在同目录下有一组互补用例共同覆盖了keep_if的边界行为快照文件输入期望输出覆盖的边界list_keep_if.mdList.keep_if([1, 2, 3, 4, 5], |x| x 2)[3.0, 4.0, 5.0]常规过滤list_keep_if_empty.mdList.keep_if([1, 2, 3], |_| Bool.False)[]谓词恒为 false全部过滤list_keep_if_none.mdList.keep_if([1, 2, 3], |x| x 10)[]无元素满足条件返回空列表list_keep_if_try.md见下文多行输出可失败谓词版本keep_if_trylist_keep_if_try.md最为丰富它在一个 SOURCE 中连续输入 7 条 REPL 表达式OUTPUT 段随之出现 7 个以---分隔的结果块展示了 REPL 快照支持多轮交互的固化格式» [1, 2, 3, 4].keep_if_try(|n| Ok(n 2)) » [1, 2, 3].keep_if_try(|n| if n 3 { Ok(n.is_even()) } else { Err(Stop) }) » [1.I64, 2, 3, 4].keep_if_try!(|n| Ok(n 2)) » List.keep_if_try([], |_| Ok(Bool.True)) » strings [a heap-allocated string long enough to not be stored inline] » List.keep_if_try(strings, |_| Ok(Bool.True)) » strings对应输出依次为Ok([3.0, 4.0]) --- Err(Stop) --- Ok([3, 4]) --- Ok([]) --- assigned strings --- Ok([a heap-allocated string long enough to not be stored inline]) --- [a heap-allocated string long enough to not be stored inline]这组输出固化了多层行为keep_if_try接受返回Result的可失败谓词遇到Err(Stop)立即短路并返回错误!后缀版本直接解包成功值空列表输入返回Ok([])而最后一条» strings单独读回原变量验证了过滤过程没有移动堆上字符串的所有权——这是 REPL 快照能够覆盖语义层面的一个典型例子。小结test/snapshots/repl/list_keep_if.md虽然只有十余行但它完整体现了 Roc 编译器以快照固化行为的测试思路四段结构META / SOURCE / OUTPUT / PROBLEMS把一条List.keep_if的输入、期望输出与零诊断断言全部固化为可 diff 的文本配合 test/snapshots/README.md 描述的 snapshot-tool 命令run-snapshot-tool、--update-expected、--trace-eval以及同族的 empty / none / try 用例形成了一套从常规过滤、空结果到可失败谓词与所有权语义的完整回归验证矩阵。对维护编译器求值行为或阅读标准库测试的开发者而言这个文件是理解 Roc 快照测试体系的最佳切入点之一。【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Roc REPL 快照测试深度解析：以 List.keep_if 过滤测试为例

相关推荐

OneUptime × Jira 双向集成实战：用 Workflow 打通事故工单的完整生命周期

OPT C# SDK实战：机器视觉上位机开发与采图流程详解

如何给PicGo贡献代码：本地开发环境搭建到提交第一个PR的完整指南

更多资讯

Quasar QTimeline 组件完全指南：三种布局、插槽体系与无障碍时间线实战

Vue Router 2 的 Route 对象完全指南：属性详解、匹配原理与不可变性实现

Orkes Conductor SQL注入漏洞分析与防护

Sentaurus TCAD半导体工艺与器件仿真：网格划分、物理模型与实战流程

Ubuntu 20.04源码编译SRS并配置systemd开机自启动全攻略

BoxMOT多目标跟踪器如何选：11种算法对比与最小验证

今日更新

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本周精选

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？