深入解析 Roc 快照测试以Bool.True Bool.True为例读懂编译器各阶段流水线【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/rocRocA fast, friendly, functional language仓库中的 bool_equality.md 是一份典型的编译器快照snapshot测试文件它记录了同一段 Roc 源码在**分词tokenize、解析parse、格式化format、规范化canonicalize、类型推断type check**各个编译阶段的精确输出。阅读本文后你将掌握快照文件的格式约定、各阶段的语义含义并学会如何生成、更新与调试这类测试从而真正理解 Roc 编译器前端流水线的工作方式。快照测试编译器行为的“金标准”在 test/snapshots/README.md 中官方对快照测试的定位做了明确说明快照测试通过捕获某段 Roc 代码在编译每个阶段的输出对编译流水线tokenization、parsing、canonicalization、type checking 等进行全面验证。每个快照文件包含期望输出当编译器行为发生意外变化时快照能帮助开发者及时发现回归regression。快照文件的结构高度统一由若干以#开头的区块组成。以bool_equality.md为例它依次包含META元信息、SOURCE被测源码、EXPECTED期望求值结果、PROBLEMS诊断报告、TOKENS分词结果、PARSE解析树、FORMATTED格式化结果、CANONICALIZE规范化 IR、TYPES类型推断结果。下面逐段拆解。META 元信息描述与类型descriptionTest Bool.True Bool.True equality typesnippetdescription一句话描述该快照验证的行为——测试Bool.True Bool.True这一等值比较type快照类型。本文件为snippet代码片段。test/snapshots/README.md 指出普通快照typefile、snippet、expr等捕获诊断的语义而typereporting的快照单独放在reporting/目录中用于固定渲染层的输出CLI、MARKDOWN、HTML、LSP 等保证“语义变化”与“展示变化”不会混在同一批文件里。另外README 还提到一个细节如果源码中包含回车符需要在 META 中增加source_escapestrue并在SOURCE中用\r书写。SOURCE 与 EXPECTED输入与期望求值结果test Bool.True Bool.TrueSOURCE是被测的完整 Roc 源码。这里定义了一个名为test的绑定其值是Bool.True Bool.True——两个布尔标签值的相等性判断。EXPECTED为NIL含义是该代码片段不求值产生具体值顶层定义而非表达式因此没有运行时结果。而PROBLEMS同样为NIL表示本次编译没有产生任何诊断报告——代码在语义上是完全合法的。TOKENS词法阶段的产出LowerIdent,OpAssign,UpperIdent,NoSpaceDotUpperIdent,OpEquals,UpperIdent,NoSpaceDotUpperIdent, EndOfFile,TOKENS区展示词法分析器lexer切分出的 token 序列每个 token 用“类别名 文本写在括号里”表示逗号分隔LowerIdent (test)小写开头的标识符即变量名OpAssign ()赋值运算符UpperIdent (Bool)大写开头的标识符即类型/模块名NoSpaceDotUpperIdent (.True)无空格的点号后接大写标识符表示“模块限定标签”的.True部分——它被单独切分是因为Bool.True中.与True之间不允许有空格OpEquals ()相等运算符EndOfFile文件结束标记。注意 token 类别命名中的“Upper/Lower Ident”区分这与 Roc 的语法约定一致类型、标签、模块名以大写开头变量以大写开头这是后续解析与类型推断能正确区分Bool命名空间与True标签的基础。PARSE语法树(file (type-mod) (statements (s-decl (p-ident (raw test)) (e-binop (op ) (e-tag (raw Bool.True)) (e-tag (raw Bool.True))))))PARSE是解析器构建的语法树S-expression 形式自上而下file→type-mod类型模块头此处为空→statementss-decl一条声明语句左值为p-ident (raw test)模式标识符右值为e-binop (op )一个二元运算表达式左、右操作数均为e-tag (raw Bool.True)——即两个标签表达式。也就是说解析阶段并不“理解”的语义只是忠实地记录这是一个二元运算及其两个操作数。二元运算节点在解析器中对应源码 src/parse/AST.zig 中的e-binop节点而顶层声明的建模s-decl、p-ident同样定义在该 AST 中。FORMATTED格式化器无改动NO CHANGEFORMATTED区用于固定 Roc 代码格式化器formatter的输出。这里显示NO CHANGE说明test Bool.True Bool.True的写法已经完全符合 Roc 的规范格式格式化器不会做任何改写。若代码风格不规整此区会给出格式化后的完整代码用于锁定格式规则。CANONICALIZE规范化 IR 中的等值比较(can-ir (d-let (p-assign (ident test)) (e-method-eq (negated false) (lhs (e-nominal-external (builtin) (e-tag (name True)))) (rhs (e-nominal-external (builtin) (e-tag (name True)))))))CANONICALIZE是规范化阶段canonicalization产出的中间表示这一阶段将表层语法解析为带语义信息的规范 IR是后续类型检查的输入d-letp-assign (ident test)顶层 let 绑定将结果赋给teste-method-eq (negated false)方法形式的相等性比较method callnegated false表示该比较未被取反。源码层面在解析时是通用e-binop到规范化阶段则被特化为e-method-eq——对应 src/canonicalize/Expression.zig 中e-method-eq节点的生成逻辑它与 src/canonicalize/Expression.zig 中保留的一般e-binop节点相互区分lhs/rhs左右操作数均为e-nominal-external (builtin) (e-tag (name True))——即内建builtin模块中名为True的外部标签。Bool是内建类型因此Bool.True被解析为对 builtin 命名空间中的标签引用而不是用户自定义枚举。这里可以清楚看到一条核心语义Bool.True Bool.True最终成为“对两个内建标签值的相等性比较”而标签True隶属于内建Bool类型。TYPES类型推断结果(inferred-types (defs (patt (type Bool))) (expressions (expr (type Bool))))TYPES区固化类型推断type inference的结论defs中patt (type Bool)绑定模式test的推断类型为Boolexpressions中expr (type Bool)比较表达式的结果类型也是Bool在 Roc 中返回Bool。值得注意的是快照只记录显式标注/推断出的表层类型而不输出完整统一的类型变量约束过程——完整的类型约束与统一逻辑位于 src/check/unify.zig快照断言的是最终可见结果。实战如何生成、更新与调试快照在 build.zig 中项目注册了run-snapshot-tool构建步骤test/snapshots/README.md 给出了完整的用法# 生成/更新所有快照 zig build run-snapshot-tool # 仅更新指定快照文件 zig build run-snapshot-tool -- test/snapshots/bool_equality.md # 若只想从诊断报告重新生成 EXPECTED/PROBLEMS 部分 zig build run-snapshot-tool -- test/snapshots/bool_equality.md --update-expected # 调试 REPL 类快照typerepl启用解释器追踪 zig build run-snapshot-tool -- src/snapshots/repl/repl_record_field_access.md --trace-eval使用注意事项--trace-eval仅适用于typerepl的快照且一次只能处理单个文件debug 构建默认开启追踪输出release 构建需要额外传入-Dtrace-evaltrue才能启用快照在生成后会被纳入版本管理若重生成后出现差异构建系统会提示运行zig build run-snapshot-tool并提交结果见 build.zig 中的回归提示逻辑。从实践角度看快照文件是理解 Roc 编译器各阶段产物最直接的教材一份bool_equality.md就完整展示了“源码 → token → 语法树 → 规范化 IR → 类型”的全程。当你修改编译器行为时快照会忠实地“曝光”每一处输出变化从而帮你定位回归发生在哪个阶段。小结通过逐段解读 bool_equality.md我们还原了 Roc 编译器对Bool.True Bool.True的完整处理链路词法层把Bool、.、True、切分为带空格约束的 token语法层构建出e-binop二元运算树规范化层把特化为e-method-eq并把Bool.True解析为 builtin 内建标签类型层推断出绑定与表达式均为Bool。同时借助 test/snapshots/README.md 与 build.zig 的说明你可以立即用zig build run-snapshot-tool在本地复现、更新并调试这类快照。对于任何希望深入 Roc 编译器前端或参与编译器开发的人来说快照目录test/snapshots/就是一本可执行、可验证的流水线说明书。【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 深入解析 Roc 快照测试：以 `Bool.True == Bool.True` 为例读懂编译器各阶段流水线
深入解析 Roc 快照测试以Bool.True Bool.True为例读懂编译器各阶段流水线【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/rocRocA fast, friendly, functional language仓库中的 bool_equality.md 是一份典型的编译器快照snapshot测试文件它记录了同一段 Roc 源码在**分词tokenize、解析parse、格式化format、规范化canonicalize、类型推断type check**各个编译阶段的精确输出。阅读本文后你将掌握快照文件的格式约定、各阶段的语义含义并学会如何生成、更新与调试这类测试从而真正理解 Roc 编译器前端流水线的工作方式。快照测试编译器行为的“金标准”在 test/snapshots/README.md 中官方对快照测试的定位做了明确说明快照测试通过捕获某段 Roc 代码在编译每个阶段的输出对编译流水线tokenization、parsing、canonicalization、type checking 等进行全面验证。每个快照文件包含期望输出当编译器行为发生意外变化时快照能帮助开发者及时发现回归regression。快照文件的结构高度统一由若干以#开头的区块组成。以bool_equality.md为例它依次包含META元信息、SOURCE被测源码、EXPECTED期望求值结果、PROBLEMS诊断报告、TOKENS分词结果、PARSE解析树、FORMATTED格式化结果、CANONICALIZE规范化 IR、TYPES类型推断结果。下面逐段拆解。META 元信息描述与类型descriptionTest Bool.True Bool.True equality typesnippetdescription一句话描述该快照验证的行为——测试Bool.True Bool.True这一等值比较type快照类型。本文件为snippet代码片段。test/snapshots/README.md 指出普通快照typefile、snippet、expr等捕获诊断的语义而typereporting的快照单独放在reporting/目录中用于固定渲染层的输出CLI、MARKDOWN、HTML、LSP 等保证“语义变化”与“展示变化”不会混在同一批文件里。另外README 还提到一个细节如果源码中包含回车符需要在 META 中增加source_escapestrue并在SOURCE中用\r书写。SOURCE 与 EXPECTED输入与期望求值结果test Bool.True Bool.TrueSOURCE是被测的完整 Roc 源码。这里定义了一个名为test的绑定其值是Bool.True Bool.True——两个布尔标签值的相等性判断。EXPECTED为NIL含义是该代码片段不求值产生具体值顶层定义而非表达式因此没有运行时结果。而PROBLEMS同样为NIL表示本次编译没有产生任何诊断报告——代码在语义上是完全合法的。TOKENS词法阶段的产出LowerIdent,OpAssign,UpperIdent,NoSpaceDotUpperIdent,OpEquals,UpperIdent,NoSpaceDotUpperIdent, EndOfFile,TOKENS区展示词法分析器lexer切分出的 token 序列每个 token 用“类别名 文本写在括号里”表示逗号分隔LowerIdent (test)小写开头的标识符即变量名OpAssign ()赋值运算符UpperIdent (Bool)大写开头的标识符即类型/模块名NoSpaceDotUpperIdent (.True)无空格的点号后接大写标识符表示“模块限定标签”的.True部分——它被单独切分是因为Bool.True中.与True之间不允许有空格OpEquals ()相等运算符EndOfFile文件结束标记。注意 token 类别命名中的“Upper/Lower Ident”区分这与 Roc 的语法约定一致类型、标签、模块名以大写开头变量以大写开头这是后续解析与类型推断能正确区分Bool命名空间与True标签的基础。PARSE语法树(file (type-mod) (statements (s-decl (p-ident (raw test)) (e-binop (op ) (e-tag (raw Bool.True)) (e-tag (raw Bool.True))))))PARSE是解析器构建的语法树S-expression 形式自上而下file→type-mod类型模块头此处为空→statementss-decl一条声明语句左值为p-ident (raw test)模式标识符右值为e-binop (op )一个二元运算表达式左、右操作数均为e-tag (raw Bool.True)——即两个标签表达式。也就是说解析阶段并不“理解”的语义只是忠实地记录这是一个二元运算及其两个操作数。二元运算节点在解析器中对应源码 src/parse/AST.zig 中的e-binop节点而顶层声明的建模s-decl、p-ident同样定义在该 AST 中。FORMATTED格式化器无改动NO CHANGEFORMATTED区用于固定 Roc 代码格式化器formatter的输出。这里显示NO CHANGE说明test Bool.True Bool.True的写法已经完全符合 Roc 的规范格式格式化器不会做任何改写。若代码风格不规整此区会给出格式化后的完整代码用于锁定格式规则。CANONICALIZE规范化 IR 中的等值比较(can-ir (d-let (p-assign (ident test)) (e-method-eq (negated false) (lhs (e-nominal-external (builtin) (e-tag (name True)))) (rhs (e-nominal-external (builtin) (e-tag (name True)))))))CANONICALIZE是规范化阶段canonicalization产出的中间表示这一阶段将表层语法解析为带语义信息的规范 IR是后续类型检查的输入d-letp-assign (ident test)顶层 let 绑定将结果赋给teste-method-eq (negated false)方法形式的相等性比较method callnegated false表示该比较未被取反。源码层面在解析时是通用e-binop到规范化阶段则被特化为e-method-eq——对应 src/canonicalize/Expression.zig 中e-method-eq节点的生成逻辑它与 src/canonicalize/Expression.zig 中保留的一般e-binop节点相互区分lhs/rhs左右操作数均为e-nominal-external (builtin) (e-tag (name True))——即内建builtin模块中名为True的外部标签。Bool是内建类型因此Bool.True被解析为对 builtin 命名空间中的标签引用而不是用户自定义枚举。这里可以清楚看到一条核心语义Bool.True Bool.True最终成为“对两个内建标签值的相等性比较”而标签True隶属于内建Bool类型。TYPES类型推断结果(inferred-types (defs (patt (type Bool))) (expressions (expr (type Bool))))TYPES区固化类型推断type inference的结论defs中patt (type Bool)绑定模式test的推断类型为Boolexpressions中expr (type Bool)比较表达式的结果类型也是Bool在 Roc 中返回Bool。值得注意的是快照只记录显式标注/推断出的表层类型而不输出完整统一的类型变量约束过程——完整的类型约束与统一逻辑位于 src/check/unify.zig快照断言的是最终可见结果。实战如何生成、更新与调试快照在 build.zig 中项目注册了run-snapshot-tool构建步骤test/snapshots/README.md 给出了完整的用法# 生成/更新所有快照 zig build run-snapshot-tool # 仅更新指定快照文件 zig build run-snapshot-tool -- test/snapshots/bool_equality.md # 若只想从诊断报告重新生成 EXPECTED/PROBLEMS 部分 zig build run-snapshot-tool -- test/snapshots/bool_equality.md --update-expected # 调试 REPL 类快照typerepl启用解释器追踪 zig build run-snapshot-tool -- src/snapshots/repl/repl_record_field_access.md --trace-eval使用注意事项--trace-eval仅适用于typerepl的快照且一次只能处理单个文件debug 构建默认开启追踪输出release 构建需要额外传入-Dtrace-evaltrue才能启用快照在生成后会被纳入版本管理若重生成后出现差异构建系统会提示运行zig build run-snapshot-tool并提交结果见 build.zig 中的回归提示逻辑。从实践角度看快照文件是理解 Roc 编译器各阶段产物最直接的教材一份bool_equality.md就完整展示了“源码 → token → 语法树 → 规范化 IR → 类型”的全程。当你修改编译器行为时快照会忠实地“曝光”每一处输出变化从而帮你定位回归发生在哪个阶段。小结通过逐段解读 bool_equality.md我们还原了 Roc 编译器对Bool.True Bool.True的完整处理链路词法层把Bool、.、True、切分为带空格约束的 token语法层构建出e-binop二元运算树规范化层把特化为e-method-eq并把Bool.True解析为 builtin 内建标签类型层推断出绑定与表达式均为Bool。同时借助 test/snapshots/README.md 与 build.zig 的说明你可以立即用zig build run-snapshot-tool在本地复现、更新并调试这类快照。对于任何希望深入 Roc 编译器前端或参与编译器开发的人来说快照目录test/snapshots/就是一本可执行、可验证的流水线说明书。【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考