设计更好的编译器诊断 — 构建 Klar 的经验教训

Source: Dev.to

我正在构建一种小型实验语言 Klar（之前叫 Klang），用来探索显式语义、严格诊断以及多语言工具链。这不是一门可投入生产的语言——它是一次设计练习——但在此过程中我一直在纠结一个具体问题：到底是什么让编译器错误真正有用？

示例诊断（用户看到的内容）

[K:E217] UnresolvedSymbol
ERROR (SEMANTIC)
at undefinedVariableExceptionTest.kl:10:12

 8 |     }
 9 |
10 |     println(total);
   |             ^

Cause:
  The variable 'total' does not exist

Fix:
  Remove it or create it

产生该诊断的源码（.kl）

@Use("java")
public void main(){
    integer count = 10;
    integer iterator = 0;

    while (iterator < count){
        iterator = iterator + 1;
    }

    println(total);

    return null;
}

设计要点（简要）

• 诊断信息 首先以数据结构化（错误码 + 元数据），再渲染为可读文本。
• 布局：简短摘要 → 精确位置（file:line:col + 插入符号） → 人类可读解释 → 可操作的修复建议。
• 避免使用玩味/友好的语言；优先考虑清晰性和可预期性。
• 建议应保守——例如，仅在置信度足够时才给出 “你是想要 X 吗？” 的提示。

向社区征求的意见

• 在评估诊断信息时，你最看重 精确度、简约性，还是 可操作的修复？
• 你更喜欢 先给出单行摘要（随后是细节），还是 一次性呈现为一段可读的文字？
• 有没有你见过的诊断模式会持续 让用户感到困惑？

我特别关注诊断信息在 噪音 与 帮助性 之间的权衡。如果你想看到更多示例（类型不匹配、缺少返回值、魔数警告等），我可以在评论中粘贴。

— ~K’（Klar 开发者）