深入 Roc 的?提前返回局部类型注解不改变 Try 解包的类型检查目标基于 roc 编译器快照测试剖析【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc本篇文章以 roc 编译器仓库中的快照测试test/snapshots/question_on_annotated_local_def.md为绝对主线完整剖析 Roc 语言中?操作符try suffix的脱糖与类型检查机制当带注解的局部定义右侧使用?解包Try值时其提前返回所对齐的返回类型是所在函数的返回类型而非局部注解本身。读完本文你将掌握 RocTry/?错误处理的核心语义、快照测试五个阶段的中间表示含义以及如何用zig build run-snapshot-tool复现验证。一、快照测试是什么roc 编译器行为的胶片roc 仓库的test/snapshots/目录存放大量快照测试test/snapshots/README.md明确指出Snapshot tests that validate compiler behavior by capturing the output of each compilation stage for specific Roc code examples.也就是说快照测试通过捕获源码经过每个编译阶段的输出来验证编译器行为——从词法TOKENS、语法PARSE、规范化CANONICALIZE到类型检查TYPES一条流水线完整呈现在单个 Markdown 文件中。当编译器行为发生意外变化时这些快照能第一时间暴露回归。每个快照文件由若干固定章节组成章节含义META元信息description一句话概括本测试验证的行为typesnippet表示这是代码片段类诊断快照SOURCE被测的 Roc 源码EXPECTED期望的顶层结果NIL表示编译成功、无输出PROBLEMS编译器产生的诊断报告集合NIL表示无任何诊断TOKENS词法分析lexing产生的 token 流PARSE语法分析parsing产生的 ASTS 表达式FORMATTED格式化器输出NO CHANGE表示源码本身已符合规范格式CANONICALIZE规范化canonicalization后的中间表示CIRTYPES推断出的类型结果本篇文章的主角question_on_annotated_local_def.md正是这样一个三段式完整快照EXPECTED与PROBLEMS均为NIL证明这段源码合法且无任何诊断而它要验证的是一个容易让类型检查器误判的微妙场景。二、被测源码一个精心设计的类型检查边界案例快照的SOURCE章节给出了全部被测代码见 test/snapshots/question_on_annotated_local_def.md# repro for https://github.com/roc-lang/roc/issues/10798 # n : U64 annotates the local, so the ? early return must be checked against # fs return type Try(U64, [BadInput]) rather than against U64. parse : Str - Try(U64, [BadInput]) parse |_| Ok(1) f |s| { n : U64 n parse(s)? Ok(n) }这段代码只有两个顶层定义却同时踩中了三个语言特性Try名义类型nominal typeparse : Str - Try(U64, [BadInput])声明parse接收Str、返回Try(U64, [BadInput])——一个只能携带Ok与Err两个 tag 的 tag 联合。parse的实现直接返回Ok(1)1被推断为U64。带类型注解的局部定义annotated local def函数f的块内第一行n : U64给局部变量n显式标注了类型U64。?后缀解包try suffixn parse(s)?在 RHS 上使用?解包parse(s)。若结果为Ok(#ok)n绑定为#ok即U64若结果为Err(#err)则从当前函数提前返回Err(#err)。注释源码第 9-10 行直接点明了本测试的核心断言n : U64标注的是局部变量所以?的提前返回必须对照f 的返回类型Try(U64, [BadInput])进行检查而不是对照U64。这正是问题 #10798 的复现如果类型检查器拿局部注解U64去核对?的提前返回那么?试图返回的Err(BadInput)与U64类型不匹配合法的代码就会被错误地拒绝。正确的行为是?的提前返回以所在函数的返回类型为准。f的函数体最终返回Ok(n)其中n已是解包后的U64因此f : Str - Try(U64, [BadInput])与parse类型一致整个程序类型自洽。三、逐阶段解读从 token 流到推断类型快照的价值在于它把编译流水线的每一个中间产物都钉在纸面上。下面按阶段拆解question_on_annotated_local_def.md中记录的中间表示。3.1 TOKENS词法层面?是独立 tokenLowerIdent,OpColon,UpperIdent,OpArrow,UpperIdent,NoSpaceOpenRound,UpperIdent,Comma,OpenSquare,UpperIdent,CloseSquare,CloseRound, LowerIdent,OpAssign,OpBar,Underscore,OpBar,UpperIdent,NoSpaceOpenRound,Int,CloseRound, LowerIdent,OpAssign,OpBar,LowerIdent,OpBar,OpenCurly, LowerIdent,OpColon,UpperIdent, LowerIdent,OpAssign,LowerIdent,NoSpaceOpenRound,LowerIdent,CloseRound,NoSpaceOpQuestion, UpperIdent,NoSpaceOpenRound,LowerIdent,CloseRound, CloseCurly, EndOfFile,逐行对应源码第 1 行parse : Str - Try(U64, [BadInput])的类型注解 token 流注意NoSpaceOpenRound表示Try与(之间无空格OpenSquare/CloseSquare表示[BadInput]的 tag 联合字面量。第 2 行parse |_| Ok(1)的 lambda 定义。第 3-6 行f |s| { ... }的块其中n : U64的注解 tokenLowerIdent,OpColon,UpperIdent与n parse(s)?的定义并列出现在块内。关键 token第 6 行末尾的NoSpaceOpQuestion——即紧跟parse(s)之后的?词法上被单独切分为OpQuestion类 token。这证明?在 Roc 语法中是一个后缀运算符不是parse调用的一部分。3.2 PARSE?生成e-question-suffix节点局部注解生成s-type-anno(s-decl (p-ident (raw f)) (e-lambda (args (p-ident (raw s))) (e-block (statements (s-type-anno (name n) (ty (name U64))) (s-decl (p-ident (raw n)) (e-question-suffix (e-apply (e-ident (raw parse)) (e-ident (raw s))))) (e-apply (e-tag (raw Ok)) (e-ident (raw n)))))))语法树清晰地展示了三件事块内第一条语句是s-type-anno——n : U64是独立的类型注解语句先于n的定义出现n的定义是s-decl其 RHS 是一个e-question-suffix节点内部包裹着parse(s)这个普通函数调用块的最终表达式是Ok(n)。e-question-suffix是?的 AST 形态它并不在语法层做任何类型判断——类型检查发生在更下游的规范化与类型推断阶段。同时注意FORMMATTED章节为NO CHANGE说明这段源码本身就是规范格式tabs 缩进、Ok(n)不带尾随逗号等。3.3 CANONICALIZE?脱糖为一个match 提前返回规范化canonicalization阶段是理解?语义的核心。快照的CANONICALIZE章节展示了脱糖后的 CIR节选(e-block (s-let (p-assign (ident n)) (e-match (match (cond (e-call (constraint-fn-var 287) (e-lookup-local (p-assign (ident parse))) (e-lookup-local (p-assign (ident s))))) (branches (branch (patterns (pattern (degenerate false) (p-nominal-external (builtin) (p-applied-tag)))) (value (e-lookup-local (p-assign (ident #ok))))) (branch (patterns (pattern (degenerate false) (p-nominal-external (builtin) (p-applied-tag)))) (value (e-return (e-nominal-external (builtin) (e-tag (name Err) (args (e-lookup-local (p-assign (ident #err))))))))))))) (e-tag (name Ok) (args (e-lookup-local (p-assign (ident n))))))这段 IR 说明?在规范化阶段被完全脱糖为对一个Try值的matchOk 分支passthrough匹配Ok(#ok)值为#ok——n因此绑定到解包后的U64值Err 分支提前返回匹配Err(#err)值为e-return (Err(#err))——从当前 lambda 提前返回一个重新包装的Err(#err)脱糖后块的最终表达式仍是Ok(n)。p-nominal-external (builtin)表明Ok/Err模式匹配的是内建Try名义类型的外部builtin表示。这个match 脱糖在 roc 编译器的源码中有直接对应实现见 src/canonicalize/Can.zig 的finishSuffixSingleQuestionExprconst try_target try self.resolveTryNominalTarget(); const scratch_top self.env.store.scratchMatchBranchTop(); try self.appendTryOkPassthroughBranch(try_target, region); // ... 构造 Err 分支的 payload 绑定、查表与返回值 ... const branch_value_idx if (self.in_expect) blk: { // 在 expect 内转为 e_expect_err } else try self.addTryReturnErr(try_target, err_lookup_idx, region); try self.appendTryMatchBranch(err_branch_pat_span, branch_value_idx, region);其中resolveTryNominalTargetCan.zig负责解析Try名义类型的目标内建导入或局部定义appendTryOkPassthroughBranchCan.zig构造Ok(#ok) - #ok分支addTryReturnErrCan.zig构造Err(#err) - return Err(#err)分支关键代码如下return if (self.enclosing_lambda) |lambda_idx| try self.env.addExpr(CIR.Expr{ .e_return .{ .expr err_tag_expr_idx, .lambda lambda_idx, .context .try_suffix, } }, region) else try self.env.pushMalformed(Expr.Idx, Diagnostic{ .return_outside_fn .{ .region region, .context .try_suffix, } });这就是本测试验证的核心机制?的 Err 分支被编译成一个带.context .try_suffix的e_return其目标lambda取自self.enclosing_lambda——即包围该?的 lambda这里是f而不是某个局部变量的注解。enclosing_lambda字段在 Can.zig 定义并在 lambda 规范化入口处保存/切换Can.zig。因此类型检查器对e_return的核对对象是f的返回类型Try(U64, [BadInput])与n : U64的局部注解无关。此外规范化器还包含warnTrailingTrySuffixCan.zig当?出现在函数返回值的尾位、其返回值本身就是函数返回的Try时会发出告警——这解释了为什么本快照中?位于赋值 RHS、且函数体末尾是显式Ok(n)属于正常的非尾位用法PROBLEMS为NIL。3.4 TYPES两个定义的类型都被推断为同一签名(defs (patt (type Str - Try(U64, [BadInput]))) (patt (type Str - Try(U64, [BadInput])))) (expressions (expr (type Str - Try(U64, [BadInput]))) (expr (type Str - Try(U64, [BadInput]))))推断结果证实parse与f的最终类型都是Str - Try(U64, [BadInput])。f没有显式注解其返回类型完全由函数体推导得出——Ok(n)提供Oktag?的 Err 提前返回提供Err(BadInput)tag两者合并为Try(U64, [BadInput])再与参数s : Str组合。整个过程中n : U64这条局部注解只约束了n自身的值类型以及parse(s)?的解包结果从未参与e_return的类型核对。四、边界情况与姊妹快照同一机制的不同切面?的返回类型语义在 roc 仓库中还有多个姊妹快照从不同角度钉住同一套规则放在一起阅读可以形成完整的语义拼图test/snapshots/try_suffix_return_mismatch.md问题 #11030?的提前返回与函数体返回类型不匹配时报错。示例中函数体以另一个parse(t)?结尾尾位?其返回值即函数返回值导致前面parse(s)?的 Err 无处可返回编译产生TYPE MISMATCH诊断not_a_try中函数体返回Str而非Try同样触发错误。它从反面印证提前返回必须落到函数的Try返回类型上。test/snapshots/eval/issue8738_question_on_non_try.md问题 #8738对非Try类型使用?时编译器给出清晰的TYPE MISMATCH提示——?操作符期望一个仅含Ok/Errtag 的Try类型并附上Maybe wrap a value using Ok(value) or Err(value)的修复建议。这证明?的合法操作对象被严格限定为Try。test/snapshots/expr/suffixed_question.mdStdout.line???这类无操作对象的裸?在解析阶段即报Unexpected Expression Syntax说明?必须作为表达式后缀或lhs ? handler二元形式出现。trailing 告警try_suffix_trailing_warning类快照与warnTrailingTrySuffixCan.zig对应检查尾位?的冗余告警与本节首个示例互为表里。这些快照共同刻画出 Roc 错误处理的完整画像Try是携带Ok/Err的名义 tag 联合?只在Try上工作解包成功绑定Ok载荷、失败则向包围它的 lambda 提前返回Err而核对提前返回的标尺永远是外层函数的返回类型。五、动手复现用快照工具验证该测试快照测试不是纸面文档roc 仓库提供了现成的命令行工具来运行与更新它们。test/snapshots/README.md记录了完整用法# 运行全部快照测试生成/校验全部快照输出 zig build run-snapshot-tool # 只运行/更新某一个快照文件 zig build run-snapshot-tool -- test/snapshots/question_on_annotated_local_def.md # 在存在诊断差异时把当前输出作为新的期望结果写入快照 zig build run-snapshot-tool -- test/snapshots/question_on_annotated_local_def.md --update-expected运行前提是仓库已按BUILDING_FROM_SOURCE.md的指引准备好 Zig 工具链本项目使用 Zig 构建系统见仓库根目录的build.zig。对于question_on_annotated_local_def.md这类typesnippet快照工具会依次执行词法、语法、规范化、类型检查并把每个阶段的输出与快照文件中记录的TOKENS/PARSE/CANONICALIZE/TYPES逐字比对任何一处输出变化都意味着编译器行为发生了改动从而把局部注解与?提前返回这条语义防线变成可自动回归检查的机器断言。六、总结question_on_annotated_local_def.md表面上只是一个 19 行的快照文件但它完整记录了 Roc 编译器处理一个类型检查边界案例的全过程证据链语法层?是独立后缀运算符NoSpaceOpQuestiontoken →e-question-suffixAST 节点规范化层?被脱糖为对Try值的matchErr 分支编译为带.context .try_suffix的e_return返回目标由enclosing_lambda决定Can.zig类型层e_return与函数返回类型Try(U64, [BadInput])核对与局部注解n : U64完全解耦回归防护EXPECTED/PROBLEMS均为NIL 五段中间表示快照任何破坏该语义的编译器改动都会在zig build run-snapshot-tool下显形。对于 Roc 学习者这段快照是理解错误处理如何与类型系统协同的最佳入门标本对于编译器开发者它示范了如何用最小化的源码构造、把一条容易回归的语义规则永久固化在测试套件里。【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 深入 Roc 的 `?` 提前返回：局部类型注解不改变 Try 解包的类型检查目标（基于 roc 编译器快照测试剖析）
深入 Roc 的?提前返回局部类型注解不改变 Try 解包的类型检查目标基于 roc 编译器快照测试剖析【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc本篇文章以 roc 编译器仓库中的快照测试test/snapshots/question_on_annotated_local_def.md为绝对主线完整剖析 Roc 语言中?操作符try suffix的脱糖与类型检查机制当带注解的局部定义右侧使用?解包Try值时其提前返回所对齐的返回类型是所在函数的返回类型而非局部注解本身。读完本文你将掌握 RocTry/?错误处理的核心语义、快照测试五个阶段的中间表示含义以及如何用zig build run-snapshot-tool复现验证。一、快照测试是什么roc 编译器行为的胶片roc 仓库的test/snapshots/目录存放大量快照测试test/snapshots/README.md明确指出Snapshot tests that validate compiler behavior by capturing the output of each compilation stage for specific Roc code examples.也就是说快照测试通过捕获源码经过每个编译阶段的输出来验证编译器行为——从词法TOKENS、语法PARSE、规范化CANONICALIZE到类型检查TYPES一条流水线完整呈现在单个 Markdown 文件中。当编译器行为发生意外变化时这些快照能第一时间暴露回归。每个快照文件由若干固定章节组成章节含义META元信息description一句话概括本测试验证的行为typesnippet表示这是代码片段类诊断快照SOURCE被测的 Roc 源码EXPECTED期望的顶层结果NIL表示编译成功、无输出PROBLEMS编译器产生的诊断报告集合NIL表示无任何诊断TOKENS词法分析lexing产生的 token 流PARSE语法分析parsing产生的 ASTS 表达式FORMATTED格式化器输出NO CHANGE表示源码本身已符合规范格式CANONICALIZE规范化canonicalization后的中间表示CIRTYPES推断出的类型结果本篇文章的主角question_on_annotated_local_def.md正是这样一个三段式完整快照EXPECTED与PROBLEMS均为NIL证明这段源码合法且无任何诊断而它要验证的是一个容易让类型检查器误判的微妙场景。二、被测源码一个精心设计的类型检查边界案例快照的SOURCE章节给出了全部被测代码见 test/snapshots/question_on_annotated_local_def.md# repro for https://github.com/roc-lang/roc/issues/10798 # n : U64 annotates the local, so the ? early return must be checked against # fs return type Try(U64, [BadInput]) rather than against U64. parse : Str - Try(U64, [BadInput]) parse |_| Ok(1) f |s| { n : U64 n parse(s)? Ok(n) }这段代码只有两个顶层定义却同时踩中了三个语言特性Try名义类型nominal typeparse : Str - Try(U64, [BadInput])声明parse接收Str、返回Try(U64, [BadInput])——一个只能携带Ok与Err两个 tag 的 tag 联合。parse的实现直接返回Ok(1)1被推断为U64。带类型注解的局部定义annotated local def函数f的块内第一行n : U64给局部变量n显式标注了类型U64。?后缀解包try suffixn parse(s)?在 RHS 上使用?解包parse(s)。若结果为Ok(#ok)n绑定为#ok即U64若结果为Err(#err)则从当前函数提前返回Err(#err)。注释源码第 9-10 行直接点明了本测试的核心断言n : U64标注的是局部变量所以?的提前返回必须对照f 的返回类型Try(U64, [BadInput])进行检查而不是对照U64。这正是问题 #10798 的复现如果类型检查器拿局部注解U64去核对?的提前返回那么?试图返回的Err(BadInput)与U64类型不匹配合法的代码就会被错误地拒绝。正确的行为是?的提前返回以所在函数的返回类型为准。f的函数体最终返回Ok(n)其中n已是解包后的U64因此f : Str - Try(U64, [BadInput])与parse类型一致整个程序类型自洽。三、逐阶段解读从 token 流到推断类型快照的价值在于它把编译流水线的每一个中间产物都钉在纸面上。下面按阶段拆解question_on_annotated_local_def.md中记录的中间表示。3.1 TOKENS词法层面?是独立 tokenLowerIdent,OpColon,UpperIdent,OpArrow,UpperIdent,NoSpaceOpenRound,UpperIdent,Comma,OpenSquare,UpperIdent,CloseSquare,CloseRound, LowerIdent,OpAssign,OpBar,Underscore,OpBar,UpperIdent,NoSpaceOpenRound,Int,CloseRound, LowerIdent,OpAssign,OpBar,LowerIdent,OpBar,OpenCurly, LowerIdent,OpColon,UpperIdent, LowerIdent,OpAssign,LowerIdent,NoSpaceOpenRound,LowerIdent,CloseRound,NoSpaceOpQuestion, UpperIdent,NoSpaceOpenRound,LowerIdent,CloseRound, CloseCurly, EndOfFile,逐行对应源码第 1 行parse : Str - Try(U64, [BadInput])的类型注解 token 流注意NoSpaceOpenRound表示Try与(之间无空格OpenSquare/CloseSquare表示[BadInput]的 tag 联合字面量。第 2 行parse |_| Ok(1)的 lambda 定义。第 3-6 行f |s| { ... }的块其中n : U64的注解 tokenLowerIdent,OpColon,UpperIdent与n parse(s)?的定义并列出现在块内。关键 token第 6 行末尾的NoSpaceOpQuestion——即紧跟parse(s)之后的?词法上被单独切分为OpQuestion类 token。这证明?在 Roc 语法中是一个后缀运算符不是parse调用的一部分。3.2 PARSE?生成e-question-suffix节点局部注解生成s-type-anno(s-decl (p-ident (raw f)) (e-lambda (args (p-ident (raw s))) (e-block (statements (s-type-anno (name n) (ty (name U64))) (s-decl (p-ident (raw n)) (e-question-suffix (e-apply (e-ident (raw parse)) (e-ident (raw s))))) (e-apply (e-tag (raw Ok)) (e-ident (raw n)))))))语法树清晰地展示了三件事块内第一条语句是s-type-anno——n : U64是独立的类型注解语句先于n的定义出现n的定义是s-decl其 RHS 是一个e-question-suffix节点内部包裹着parse(s)这个普通函数调用块的最终表达式是Ok(n)。e-question-suffix是?的 AST 形态它并不在语法层做任何类型判断——类型检查发生在更下游的规范化与类型推断阶段。同时注意FORMMATTED章节为NO CHANGE说明这段源码本身就是规范格式tabs 缩进、Ok(n)不带尾随逗号等。3.3 CANONICALIZE?脱糖为一个match 提前返回规范化canonicalization阶段是理解?语义的核心。快照的CANONICALIZE章节展示了脱糖后的 CIR节选(e-block (s-let (p-assign (ident n)) (e-match (match (cond (e-call (constraint-fn-var 287) (e-lookup-local (p-assign (ident parse))) (e-lookup-local (p-assign (ident s))))) (branches (branch (patterns (pattern (degenerate false) (p-nominal-external (builtin) (p-applied-tag)))) (value (e-lookup-local (p-assign (ident #ok))))) (branch (patterns (pattern (degenerate false) (p-nominal-external (builtin) (p-applied-tag)))) (value (e-return (e-nominal-external (builtin) (e-tag (name Err) (args (e-lookup-local (p-assign (ident #err))))))))))))) (e-tag (name Ok) (args (e-lookup-local (p-assign (ident n))))))这段 IR 说明?在规范化阶段被完全脱糖为对一个Try值的matchOk 分支passthrough匹配Ok(#ok)值为#ok——n因此绑定到解包后的U64值Err 分支提前返回匹配Err(#err)值为e-return (Err(#err))——从当前 lambda 提前返回一个重新包装的Err(#err)脱糖后块的最终表达式仍是Ok(n)。p-nominal-external (builtin)表明Ok/Err模式匹配的是内建Try名义类型的外部builtin表示。这个match 脱糖在 roc 编译器的源码中有直接对应实现见 src/canonicalize/Can.zig 的finishSuffixSingleQuestionExprconst try_target try self.resolveTryNominalTarget(); const scratch_top self.env.store.scratchMatchBranchTop(); try self.appendTryOkPassthroughBranch(try_target, region); // ... 构造 Err 分支的 payload 绑定、查表与返回值 ... const branch_value_idx if (self.in_expect) blk: { // 在 expect 内转为 e_expect_err } else try self.addTryReturnErr(try_target, err_lookup_idx, region); try self.appendTryMatchBranch(err_branch_pat_span, branch_value_idx, region);其中resolveTryNominalTargetCan.zig负责解析Try名义类型的目标内建导入或局部定义appendTryOkPassthroughBranchCan.zig构造Ok(#ok) - #ok分支addTryReturnErrCan.zig构造Err(#err) - return Err(#err)分支关键代码如下return if (self.enclosing_lambda) |lambda_idx| try self.env.addExpr(CIR.Expr{ .e_return .{ .expr err_tag_expr_idx, .lambda lambda_idx, .context .try_suffix, } }, region) else try self.env.pushMalformed(Expr.Idx, Diagnostic{ .return_outside_fn .{ .region region, .context .try_suffix, } });这就是本测试验证的核心机制?的 Err 分支被编译成一个带.context .try_suffix的e_return其目标lambda取自self.enclosing_lambda——即包围该?的 lambda这里是f而不是某个局部变量的注解。enclosing_lambda字段在 Can.zig 定义并在 lambda 规范化入口处保存/切换Can.zig。因此类型检查器对e_return的核对对象是f的返回类型Try(U64, [BadInput])与n : U64的局部注解无关。此外规范化器还包含warnTrailingTrySuffixCan.zig当?出现在函数返回值的尾位、其返回值本身就是函数返回的Try时会发出告警——这解释了为什么本快照中?位于赋值 RHS、且函数体末尾是显式Ok(n)属于正常的非尾位用法PROBLEMS为NIL。3.4 TYPES两个定义的类型都被推断为同一签名(defs (patt (type Str - Try(U64, [BadInput]))) (patt (type Str - Try(U64, [BadInput])))) (expressions (expr (type Str - Try(U64, [BadInput]))) (expr (type Str - Try(U64, [BadInput]))))推断结果证实parse与f的最终类型都是Str - Try(U64, [BadInput])。f没有显式注解其返回类型完全由函数体推导得出——Ok(n)提供Oktag?的 Err 提前返回提供Err(BadInput)tag两者合并为Try(U64, [BadInput])再与参数s : Str组合。整个过程中n : U64这条局部注解只约束了n自身的值类型以及parse(s)?的解包结果从未参与e_return的类型核对。四、边界情况与姊妹快照同一机制的不同切面?的返回类型语义在 roc 仓库中还有多个姊妹快照从不同角度钉住同一套规则放在一起阅读可以形成完整的语义拼图test/snapshots/try_suffix_return_mismatch.md问题 #11030?的提前返回与函数体返回类型不匹配时报错。示例中函数体以另一个parse(t)?结尾尾位?其返回值即函数返回值导致前面parse(s)?的 Err 无处可返回编译产生TYPE MISMATCH诊断not_a_try中函数体返回Str而非Try同样触发错误。它从反面印证提前返回必须落到函数的Try返回类型上。test/snapshots/eval/issue8738_question_on_non_try.md问题 #8738对非Try类型使用?时编译器给出清晰的TYPE MISMATCH提示——?操作符期望一个仅含Ok/Errtag 的Try类型并附上Maybe wrap a value using Ok(value) or Err(value)的修复建议。这证明?的合法操作对象被严格限定为Try。test/snapshots/expr/suffixed_question.mdStdout.line???这类无操作对象的裸?在解析阶段即报Unexpected Expression Syntax说明?必须作为表达式后缀或lhs ? handler二元形式出现。trailing 告警try_suffix_trailing_warning类快照与warnTrailingTrySuffixCan.zig对应检查尾位?的冗余告警与本节首个示例互为表里。这些快照共同刻画出 Roc 错误处理的完整画像Try是携带Ok/Err的名义 tag 联合?只在Try上工作解包成功绑定Ok载荷、失败则向包围它的 lambda 提前返回Err而核对提前返回的标尺永远是外层函数的返回类型。五、动手复现用快照工具验证该测试快照测试不是纸面文档roc 仓库提供了现成的命令行工具来运行与更新它们。test/snapshots/README.md记录了完整用法# 运行全部快照测试生成/校验全部快照输出 zig build run-snapshot-tool # 只运行/更新某一个快照文件 zig build run-snapshot-tool -- test/snapshots/question_on_annotated_local_def.md # 在存在诊断差异时把当前输出作为新的期望结果写入快照 zig build run-snapshot-tool -- test/snapshots/question_on_annotated_local_def.md --update-expected运行前提是仓库已按BUILDING_FROM_SOURCE.md的指引准备好 Zig 工具链本项目使用 Zig 构建系统见仓库根目录的build.zig。对于question_on_annotated_local_def.md这类typesnippet快照工具会依次执行词法、语法、规范化、类型检查并把每个阶段的输出与快照文件中记录的TOKENS/PARSE/CANONICALIZE/TYPES逐字比对任何一处输出变化都意味着编译器行为发生了改动从而把局部注解与?提前返回这条语义防线变成可自动回归检查的机器断言。六、总结question_on_annotated_local_def.md表面上只是一个 19 行的快照文件但它完整记录了 Roc 编译器处理一个类型检查边界案例的全过程证据链语法层?是独立后缀运算符NoSpaceOpQuestiontoken →e-question-suffixAST 节点规范化层?被脱糖为对Try值的matchErr 分支编译为带.context .try_suffix的e_return返回目标由enclosing_lambda决定Can.zig类型层e_return与函数返回类型Try(U64, [BadInput])核对与局部注解n : U64完全解耦回归防护EXPECTED/PROBLEMS均为NIL 五段中间表示快照任何破坏该语义的编译器改动都会在zig build run-snapshot-tool下显形。对于 Roc 学习者这段快照是理解错误处理如何与类型系统协同的最佳入门标本对于编译器开发者它示范了如何用最小化的源码构造、把一条容易回归的语义规则永久固化在测试套件里。【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考