Roc 编译器穷尽性检查器如何处理多态类型错误传播机制与源码解析【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc本文以 Roc 仓库的设计澄清文档 002_polymorphic_types.md 为主体结合 src/check/exhaustive.zig 与 src/check/Check.zig 的当前实现完整讲解 Roc 编译器在 match 表达式的穷尽性检查exhaustiveness checking中如何对待 scrutinee被匹配值类型为多态类型未解析类型变量这一情形历史问题、当前通过错误跳过的设计决策、源码中的完整错误传播链以及未来三种可能的演进方向。读完本文你将理解这一被标记为 BY DESIGN 的跳过行为的触发条件与边界并知道如何在仓库中定位与验证相关行为。1. 背景穷尽性检查在编译器流水线中的位置Roc 的 match 表达式在通过类型检查后还要经过一轮穷尽性与冗余性分析检查器会验证所有分支的 pattern 是否覆盖了 scrutinee 类型的全部构造子constructor若遗漏则向用户报告 missing patterns。这一分析的入口是 checkMatch其文档注释明确写道它是类型检查器的主入口main entry point for the type checker采用1-phase on-demand resolution设计pattern 先被转换成未解析sketched/unresolved形态在 usefulness 检查过程中按需利用类型信息解析。问题文档002_polymorphic_types.md讨论的核心边界情形是当 scrutinee 的类型变量在多轮推理后仍未被解析为具体类型即仍是多态类型时穷尽性检查器应如何行动该文档当前的状态标记为Status: DEFERRED / BY DESIGN即跳过检查不是 bug而是有意的、经论证的设计决策进一步的改进被列为低优先级的未来工作。2. 设计结论为什么跳过是正确行为文档给出了当前行为的精确定义当 match 表达式的条件scrutinee具有多态类型时穷尽性检查通过error.TypeError被跳过。设计澄清部分列出了两种跳过是正确的典型场景类型本身是错误类型erroneous type——类型不匹配的错误已经被别的检查机制报告过了穷尽性检查器没有再报一次错的价值类型在合法的泛型代码中确实多态——检查器无法得知该类型拥有哪些构造子报缺某分支会误导用户。文档同时说明曾经存在的 reified 路径基于ReifiedRows.has_unresolved_ctor标志位的那套逻辑已作为死代码dead code从代码库中移除现在的统一做法是走 sketched 路径由 error.TypeError 触发 Check.zig 中的静默跳过。未来工作可以为多态类型增加基于约束的检查constraint-based checking但由于最常见的情形类型错误已被正确处理这并非高优先级事项。3. 历史问题多态 match 曾静默漏检文档保留了原始问题陈述Historical Problem Statement理解它能解释当前错误模型的由来。3.1 原始问题当 scrutinee 是尚未解析到具体类型的类型变量多态类型时穷尽性检查器会完全跳过检查。这意味着用户即使写出了应报错的 match也收不到任何穷尽性错误。文档给出的 Roc 示例# x has type a (polymorphic) match x { Ok(val) val # Missing: Err case }这里x的类型是泛型变量a。由于x是多态的穷尽性检查被静默跳过——尽管用户从Ok(val)分支显然在按Result类型匹配遗漏Err分支本应提示。3.2 当时期望的正确行为文档列出过三种期望的应对方式延迟检查Defer checking等类型解析完成后再检查保守检查Conservative checking因为类型未知报告该 match 可能不穷尽基于约束的检查Constraint-based checking利用类型约束推断需要哪些 pattern。这也就是第 7 节未来演进方向的三个来源。4. 根因flex 与 rigid 类型变量文档的 Root Cause 一节解释了类型系统层面的原因。Roc 的类型系统使用两类类型变量表示多态Flex 变量flexible可与任意类型统一如List a中的a在推理过程中会被具体化Rigid 变量rigid必须保持多态如forall a. a - a中的a对应对外暴露的泛型签名。当穷尽性检查器遇到这两类变量时它没有任何关于该类型拥有哪些构造子的信息因此只能放弃give up。这一判断在源码中体现得非常直接——getUnionFromType 中对flex/rigid分支的处理// Polymorphic types (flex/rigid vars) cannot be treated as unions because // we dont know what constructors they have. This is correct behavior - // the caller should handle this by skipping exhaustiveness checking. .flex, .rigid return .not_a_union,见 src/check/exhaustive.zig#L1049-L1052。注释本身就宣告了这是正确行为并把跳过的责任显式交给调用方——这个契约在第 5.4 节的调用方代码中得到履行。值得注意的是同一函数中与之对比的路径对于具名类型nominal type如Try、Result检查器通过 openNominalBacking 将类型声明的 backing 模板按实际参数实例化从而拿到底层 tag union 的全部构造子。具名类型之所以可行正是因为参数已具体而 flex/rigid 变量没有结构可言二者在机制上不可类比。5. 当前实现完整的错误传播链从源码结构看多态 → 跳过并非散落各处的隐式行为而是一条清晰的、以错误类型为载体的传播链。以下逐环节解析。5.1 错误模型PatternResolveError检查器专门定义了 pattern 解析阶段的错误集合src/check/exhaustive.zig#L959-L965/// Errors that can occur during pattern resolution. /// These indicate type mismatches that prevent exhaustiveness checking. pub const PatternResolveError error{ OutOfMemory, /// Type couldnt be resolved (e.g., polymorphic type with unknown structure) TypeError, };TypeError的注释直接点明其语义类型无法被解析例如结构未知的多态类型。与之配套的结果联合类型是const UnionResult union(enum) { success: Union, not_a_union, };getUnionFromType返回.not_a_union只是内部信号一旦该信号出现在需要构造子展开的位置如 pattern 解析时它会被提升为error.TypeError向上抛出。例如 src/check/exhaustive.zig#L2346-L2349const union_result try getUnionFromType(allocator, type_store, builtin_idents, first_col_type); switch (union_result) { .not_a_union return error.TypeError, ...5.2 checkMatch 入口的错误契约主入口 checkMatch 的签名是PatternResolveError!CheckResult其文档注释把调用方义务写死在接口上Returnserror.TypeErrorwhen a pattern cannot be resolved due to type issues (e.g., polymorphic types, type mismatches).The caller should handle this by skipping exhaustiveness error reporting for that match expression.即多态类型导致解析失败时错误不是被吞掉而是作为显式的错误值返回由调用方决定静默跳过这一用户可见行为。函数内部流程为Phase 1 把 CIR pattern 转换为 sketched patternPhase 2 起进入 redundancy/exhaustiveness 检查期间按需解析——解析失败即沿此错误通道退出。5.3 调用方Check.zig 中的静默跳过类型检查主流程 Check.zig 在检查完 match 的分支之后才调用exhaustive.checkMatch。调用前有一组前置守卫src/check/Check.zig#L23005-L23014// Only do this if there were no type errors - type errors can lead to invalid types // that confuse the exhaustiveness checker // Also skip if the condition type is an error type ... const resolved_cond self.types.resolveVar(cond_var); const cond_is_error resolved_cond.desc.content .err; if (!match.skip_exhaustiveness and !had_type_error and !cond_is_error and !has_invalid_try and !cond_always_crashes) {这说明检查器在进入穷尽性分析前已先行排除了条件类型是 error 类型等明显病态情形——与文档中类型错误场景优先由其他机制处理的澄清一致。进入checkMatch后对error.TypeError的处理是src/check/Check.zig#L23044-L23052const result result_or_err catch |err| switch (err) { error.OutOfMemory return error.OutOfMemory, error.TypeError { // Type error in pattern - exhaustiveness checking cant proceed // This is expected when there are polymorphic types or type mismatches // Dont report exhaustiveness errors in this case return does_fx; }, };语义很明确OutOfMemory如实向上传播TypeError则不报告任何穷尽性问题直接结束该 match 的表达式检查返回does_fx。这就是文档所说的 silent skip 的确切落点——它不是忘了查而是确认查不了且查不了的原因已有归属。5.4 不可证伪绑定路径共享同一契约同一错误契约还覆盖 match 之外的分析点函数参数、let解构等不可证伪irrefutable绑定位置的 pattern 穷尽性检查checkPatternExhaustiveness走exhaustive.checkDestructure对error.TypeError同样选择静默放弃src/check/Check.zig#L21346-L21349error.TypeError return false。从源码结构看多态类型导致的无法解析在整个 checker 中是统一降级为不产生穷尽性诊断而不是在局部打补丁。5.5 死代码清理has_unresolved_ctor 已不存在文档记载的历史实现中曾有一个标志位用于追踪是否有构造子 pattern 未能完全解析/// True if any constructor patterns couldnt be fully resolved /// (e.g., polymorphic types where the union structure isnt known). /// TODO: We should handle polymorphic types properly instead of skipping checks. has_unresolved_ctor: bool,按文档说明承载该字段的 reified 路径已作为死代码移除。在当前 src/check/exhaustive.zig 中检索has_unresolved_ctor已无任何匹配可以确认清理已完成——如今代码库里只保留一条错误通道避免了标志位 错误两套跳过机制并存的状态。6. 类型解析顺序为什么检查时大多数类型已是具体的文档给出的推理时序解释了为什么多态跳过只是少数情形而非常态类型推断先行inference 阶段会解析掉大多数类型变量穷尽性检查在推断完成之后运行因此到检查时多数类型应当是具体的concrete但仍有一部分类型保持多态——典型如泛型函数体内的 match其 scrutinee 类型由函数签名中的 rigid 变量决定天然无法具体化。这与 exhaustive.zig 的注释呼应In the 1-phase design, resolution happens on-demand during usefulness checking, and type errors are propagated immediately rather than silently skipped.——立即传播错误而非静默跳过发生在检查器内部静默跳过只发生在 checker 与调用方的边界上且是显式约定的降级。7. 未来演进方向三种被记录在案的方案文档将约束式检查列为低优先级未来工作并系统性地记录了三种候选方案。它们对当前架构的侵入程度递增方案 A约束式检查Constraint-Based Checking以Ok(val)这样的 pattern 为例即便不知道x的完整类型也可以确定该类型至少是包含Ok构造子的 union。据此可以记录Ok已被覆盖要求用户要么提供通配符要么显式处理其余情形。这是对现有Union表示的增量扩展getUnionFromType在遇到 flex/rigid 时不再只返回.not_a_union而是返回一个多态类型的新变体让ReifiedRows级别的是否全部解析判断变成可操作信息。方案 B保守报告Conservative Reporting类型多态时检查已存在的 pattern若没有 wildcard/catch-all警告warn该 match 可能不穷尽警告信息中说明类型是多态的这一原因。代价是泛型代码中可能出现误报收益是用户不再面对静默无反馈。方案 C延迟检查Deferred Checking记录那些当时无法检查的 match 表达式等类型信息更充分后重新检查文档明确指出受当前编译器架构限制这一方案可能不可行。需要改动的关键函数文档列出了实现上述任一方案时的落点按当前源码位置校准函数 / 结构当前职责演进方向getUnionFromType()src/check/exhaustive.zig#L1029flex/rigid 返回.not_a_union返回表示多态类型的新变体reifyPattern系列按需解析路径如 src/check/exhaustive.zig#L2346-L2349解析失败即error.TypeError为多态类型构造特殊 pattern 表示checkMatch()src/check/exhaustive.zig#L4200主入口错误契约见注释增加多态类型的处理分支ReifiedRows相关结构行/列状态管理把是否可操作的语义做实8. 验证要点测试计划与验收标准文档给出了可操作的验证清单可作为阅读或测试本机制时的核对依据。8.1 建议的测试用例对多态类型的值做 match 且没有wildcard → 期望给出警告按未来方案或按当前设计静默跳过且不误报对多态类型的值做 match 且有wildcard → 应当 OK泛型函数体内含 match 表达式 → 验证处理路径正确多态类型随后被解析为具体类型 → 验证检查照常发生。8.2 验收标准对多态类型的 match不再被静默跳过指未来方案落地后用户会收到针对潜在不穷尽 match 的恰当警告/错误含 wildcard 的多态 match 被正确处理清晰的错误信息解释类型为何是多态的代码库中不再残留 TODO、has_unresolved_ctor式的权宜标志或静默跳过路径当前版本已达成无has_unresolved_ctor一项可用全文检索确认方案对 flex 与 rigid 变量都给出恰当处理。9. 小结这篇设计澄清文档的核心价值在于把多态 match 不报穷尽性错误从一个疑似 bug 定性为BY DESIGN的决策并展示了其工程落地检查器内部用 PatternResolveError.TypeError 显式表达类型无法解析checkMatch 把它作为接口契约抛出Check.zig 在边界上将其翻译为不产生穷尽性诊断的静默降级历史上基于has_unresolved_ctor的第二条跳过路径已清理完毕。对多态类型做更精细的约束式检查仍是开放问题文档完整记录了三种候选方案与各自的架构代价为后续改进留出了明确入口。相关文件索引主体文档CONTRIBUTING/exhaustiveness/002_polymorphic_types.md检查器实现src/check/exhaustive.ziggetUnionFromType、checkMatch、PatternResolveError类型检查主流程src/check/Check.zigmatch 穷尽性调用点、error.TypeError降级点同系列问题追踪文档目录CONTRIBUTING/exhaustiveness/【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Roc 编译器穷尽性检查器如何处理多态类型：错误传播机制与源码解析
Roc 编译器穷尽性检查器如何处理多态类型错误传播机制与源码解析【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc本文以 Roc 仓库的设计澄清文档 002_polymorphic_types.md 为主体结合 src/check/exhaustive.zig 与 src/check/Check.zig 的当前实现完整讲解 Roc 编译器在 match 表达式的穷尽性检查exhaustiveness checking中如何对待 scrutinee被匹配值类型为多态类型未解析类型变量这一情形历史问题、当前通过错误跳过的设计决策、源码中的完整错误传播链以及未来三种可能的演进方向。读完本文你将理解这一被标记为 BY DESIGN 的跳过行为的触发条件与边界并知道如何在仓库中定位与验证相关行为。1. 背景穷尽性检查在编译器流水线中的位置Roc 的 match 表达式在通过类型检查后还要经过一轮穷尽性与冗余性分析检查器会验证所有分支的 pattern 是否覆盖了 scrutinee 类型的全部构造子constructor若遗漏则向用户报告 missing patterns。这一分析的入口是 checkMatch其文档注释明确写道它是类型检查器的主入口main entry point for the type checker采用1-phase on-demand resolution设计pattern 先被转换成未解析sketched/unresolved形态在 usefulness 检查过程中按需利用类型信息解析。问题文档002_polymorphic_types.md讨论的核心边界情形是当 scrutinee 的类型变量在多轮推理后仍未被解析为具体类型即仍是多态类型时穷尽性检查器应如何行动该文档当前的状态标记为Status: DEFERRED / BY DESIGN即跳过检查不是 bug而是有意的、经论证的设计决策进一步的改进被列为低优先级的未来工作。2. 设计结论为什么跳过是正确行为文档给出了当前行为的精确定义当 match 表达式的条件scrutinee具有多态类型时穷尽性检查通过error.TypeError被跳过。设计澄清部分列出了两种跳过是正确的典型场景类型本身是错误类型erroneous type——类型不匹配的错误已经被别的检查机制报告过了穷尽性检查器没有再报一次错的价值类型在合法的泛型代码中确实多态——检查器无法得知该类型拥有哪些构造子报缺某分支会误导用户。文档同时说明曾经存在的 reified 路径基于ReifiedRows.has_unresolved_ctor标志位的那套逻辑已作为死代码dead code从代码库中移除现在的统一做法是走 sketched 路径由 error.TypeError 触发 Check.zig 中的静默跳过。未来工作可以为多态类型增加基于约束的检查constraint-based checking但由于最常见的情形类型错误已被正确处理这并非高优先级事项。3. 历史问题多态 match 曾静默漏检文档保留了原始问题陈述Historical Problem Statement理解它能解释当前错误模型的由来。3.1 原始问题当 scrutinee 是尚未解析到具体类型的类型变量多态类型时穷尽性检查器会完全跳过检查。这意味着用户即使写出了应报错的 match也收不到任何穷尽性错误。文档给出的 Roc 示例# x has type a (polymorphic) match x { Ok(val) val # Missing: Err case }这里x的类型是泛型变量a。由于x是多态的穷尽性检查被静默跳过——尽管用户从Ok(val)分支显然在按Result类型匹配遗漏Err分支本应提示。3.2 当时期望的正确行为文档列出过三种期望的应对方式延迟检查Defer checking等类型解析完成后再检查保守检查Conservative checking因为类型未知报告该 match 可能不穷尽基于约束的检查Constraint-based checking利用类型约束推断需要哪些 pattern。这也就是第 7 节未来演进方向的三个来源。4. 根因flex 与 rigid 类型变量文档的 Root Cause 一节解释了类型系统层面的原因。Roc 的类型系统使用两类类型变量表示多态Flex 变量flexible可与任意类型统一如List a中的a在推理过程中会被具体化Rigid 变量rigid必须保持多态如forall a. a - a中的a对应对外暴露的泛型签名。当穷尽性检查器遇到这两类变量时它没有任何关于该类型拥有哪些构造子的信息因此只能放弃give up。这一判断在源码中体现得非常直接——getUnionFromType 中对flex/rigid分支的处理// Polymorphic types (flex/rigid vars) cannot be treated as unions because // we dont know what constructors they have. This is correct behavior - // the caller should handle this by skipping exhaustiveness checking. .flex, .rigid return .not_a_union,见 src/check/exhaustive.zig#L1049-L1052。注释本身就宣告了这是正确行为并把跳过的责任显式交给调用方——这个契约在第 5.4 节的调用方代码中得到履行。值得注意的是同一函数中与之对比的路径对于具名类型nominal type如Try、Result检查器通过 openNominalBacking 将类型声明的 backing 模板按实际参数实例化从而拿到底层 tag union 的全部构造子。具名类型之所以可行正是因为参数已具体而 flex/rigid 变量没有结构可言二者在机制上不可类比。5. 当前实现完整的错误传播链从源码结构看多态 → 跳过并非散落各处的隐式行为而是一条清晰的、以错误类型为载体的传播链。以下逐环节解析。5.1 错误模型PatternResolveError检查器专门定义了 pattern 解析阶段的错误集合src/check/exhaustive.zig#L959-L965/// Errors that can occur during pattern resolution. /// These indicate type mismatches that prevent exhaustiveness checking. pub const PatternResolveError error{ OutOfMemory, /// Type couldnt be resolved (e.g., polymorphic type with unknown structure) TypeError, };TypeError的注释直接点明其语义类型无法被解析例如结构未知的多态类型。与之配套的结果联合类型是const UnionResult union(enum) { success: Union, not_a_union, };getUnionFromType返回.not_a_union只是内部信号一旦该信号出现在需要构造子展开的位置如 pattern 解析时它会被提升为error.TypeError向上抛出。例如 src/check/exhaustive.zig#L2346-L2349const union_result try getUnionFromType(allocator, type_store, builtin_idents, first_col_type); switch (union_result) { .not_a_union return error.TypeError, ...5.2 checkMatch 入口的错误契约主入口 checkMatch 的签名是PatternResolveError!CheckResult其文档注释把调用方义务写死在接口上Returnserror.TypeErrorwhen a pattern cannot be resolved due to type issues (e.g., polymorphic types, type mismatches).The caller should handle this by skipping exhaustiveness error reporting for that match expression.即多态类型导致解析失败时错误不是被吞掉而是作为显式的错误值返回由调用方决定静默跳过这一用户可见行为。函数内部流程为Phase 1 把 CIR pattern 转换为 sketched patternPhase 2 起进入 redundancy/exhaustiveness 检查期间按需解析——解析失败即沿此错误通道退出。5.3 调用方Check.zig 中的静默跳过类型检查主流程 Check.zig 在检查完 match 的分支之后才调用exhaustive.checkMatch。调用前有一组前置守卫src/check/Check.zig#L23005-L23014// Only do this if there were no type errors - type errors can lead to invalid types // that confuse the exhaustiveness checker // Also skip if the condition type is an error type ... const resolved_cond self.types.resolveVar(cond_var); const cond_is_error resolved_cond.desc.content .err; if (!match.skip_exhaustiveness and !had_type_error and !cond_is_error and !has_invalid_try and !cond_always_crashes) {这说明检查器在进入穷尽性分析前已先行排除了条件类型是 error 类型等明显病态情形——与文档中类型错误场景优先由其他机制处理的澄清一致。进入checkMatch后对error.TypeError的处理是src/check/Check.zig#L23044-L23052const result result_or_err catch |err| switch (err) { error.OutOfMemory return error.OutOfMemory, error.TypeError { // Type error in pattern - exhaustiveness checking cant proceed // This is expected when there are polymorphic types or type mismatches // Dont report exhaustiveness errors in this case return does_fx; }, };语义很明确OutOfMemory如实向上传播TypeError则不报告任何穷尽性问题直接结束该 match 的表达式检查返回does_fx。这就是文档所说的 silent skip 的确切落点——它不是忘了查而是确认查不了且查不了的原因已有归属。5.4 不可证伪绑定路径共享同一契约同一错误契约还覆盖 match 之外的分析点函数参数、let解构等不可证伪irrefutable绑定位置的 pattern 穷尽性检查checkPatternExhaustiveness走exhaustive.checkDestructure对error.TypeError同样选择静默放弃src/check/Check.zig#L21346-L21349error.TypeError return false。从源码结构看多态类型导致的无法解析在整个 checker 中是统一降级为不产生穷尽性诊断而不是在局部打补丁。5.5 死代码清理has_unresolved_ctor 已不存在文档记载的历史实现中曾有一个标志位用于追踪是否有构造子 pattern 未能完全解析/// True if any constructor patterns couldnt be fully resolved /// (e.g., polymorphic types where the union structure isnt known). /// TODO: We should handle polymorphic types properly instead of skipping checks. has_unresolved_ctor: bool,按文档说明承载该字段的 reified 路径已作为死代码移除。在当前 src/check/exhaustive.zig 中检索has_unresolved_ctor已无任何匹配可以确认清理已完成——如今代码库里只保留一条错误通道避免了标志位 错误两套跳过机制并存的状态。6. 类型解析顺序为什么检查时大多数类型已是具体的文档给出的推理时序解释了为什么多态跳过只是少数情形而非常态类型推断先行inference 阶段会解析掉大多数类型变量穷尽性检查在推断完成之后运行因此到检查时多数类型应当是具体的concrete但仍有一部分类型保持多态——典型如泛型函数体内的 match其 scrutinee 类型由函数签名中的 rigid 变量决定天然无法具体化。这与 exhaustive.zig 的注释呼应In the 1-phase design, resolution happens on-demand during usefulness checking, and type errors are propagated immediately rather than silently skipped.——立即传播错误而非静默跳过发生在检查器内部静默跳过只发生在 checker 与调用方的边界上且是显式约定的降级。7. 未来演进方向三种被记录在案的方案文档将约束式检查列为低优先级未来工作并系统性地记录了三种候选方案。它们对当前架构的侵入程度递增方案 A约束式检查Constraint-Based Checking以Ok(val)这样的 pattern 为例即便不知道x的完整类型也可以确定该类型至少是包含Ok构造子的 union。据此可以记录Ok已被覆盖要求用户要么提供通配符要么显式处理其余情形。这是对现有Union表示的增量扩展getUnionFromType在遇到 flex/rigid 时不再只返回.not_a_union而是返回一个多态类型的新变体让ReifiedRows级别的是否全部解析判断变成可操作信息。方案 B保守报告Conservative Reporting类型多态时检查已存在的 pattern若没有 wildcard/catch-all警告warn该 match 可能不穷尽警告信息中说明类型是多态的这一原因。代价是泛型代码中可能出现误报收益是用户不再面对静默无反馈。方案 C延迟检查Deferred Checking记录那些当时无法检查的 match 表达式等类型信息更充分后重新检查文档明确指出受当前编译器架构限制这一方案可能不可行。需要改动的关键函数文档列出了实现上述任一方案时的落点按当前源码位置校准函数 / 结构当前职责演进方向getUnionFromType()src/check/exhaustive.zig#L1029flex/rigid 返回.not_a_union返回表示多态类型的新变体reifyPattern系列按需解析路径如 src/check/exhaustive.zig#L2346-L2349解析失败即error.TypeError为多态类型构造特殊 pattern 表示checkMatch()src/check/exhaustive.zig#L4200主入口错误契约见注释增加多态类型的处理分支ReifiedRows相关结构行/列状态管理把是否可操作的语义做实8. 验证要点测试计划与验收标准文档给出了可操作的验证清单可作为阅读或测试本机制时的核对依据。8.1 建议的测试用例对多态类型的值做 match 且没有wildcard → 期望给出警告按未来方案或按当前设计静默跳过且不误报对多态类型的值做 match 且有wildcard → 应当 OK泛型函数体内含 match 表达式 → 验证处理路径正确多态类型随后被解析为具体类型 → 验证检查照常发生。8.2 验收标准对多态类型的 match不再被静默跳过指未来方案落地后用户会收到针对潜在不穷尽 match 的恰当警告/错误含 wildcard 的多态 match 被正确处理清晰的错误信息解释类型为何是多态的代码库中不再残留 TODO、has_unresolved_ctor式的权宜标志或静默跳过路径当前版本已达成无has_unresolved_ctor一项可用全文检索确认方案对 flex 与 rigid 变量都给出恰当处理。9. 小结这篇设计澄清文档的核心价值在于把多态 match 不报穷尽性错误从一个疑似 bug 定性为BY DESIGN的决策并展示了其工程落地检查器内部用 PatternResolveError.TypeError 显式表达类型无法解析checkMatch 把它作为接口契约抛出Check.zig 在边界上将其翻译为不产生穷尽性诊断的静默降级历史上基于has_unresolved_ctor的第二条跳过路径已清理完毕。对多态类型做更精细的约束式检查仍是开放问题文档完整记录了三种候选方案与各自的架构代价为后续改进留出了明确入口。相关文件索引主体文档CONTRIBUTING/exhaustiveness/002_polymorphic_types.md检查器实现src/check/exhaustive.ziggetUnionFromType、checkMatch、PatternResolveError类型检查主流程src/check/Check.zigmatch 穷尽性调用点、error.TypeError降级点同系列问题追踪文档目录CONTRIBUTING/exhaustiveness/【免费下载链接】rocA fast, friendly, functional language.项目地址: https://gitcode.com/GitHub_Trending/ro/roc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考