Clang通过-ferror-limit=N限制错误数，超出即中止编译；该选项仅作用于前端诊断，不影响警告或后端工具（llc/opt）报错，且错误常由前置问题引发连锁反应。
LLVM 默认不限制报错数量，但 Clang（LLVM 的 C/C++ 前端）支持通过 -ferror-limit 控制最大错误数，超出后直接中止编译。
Clang 的 -ferror-limit 是唯一有效手段
LLVM 本身不处理语法/语义错误，那是前端职责。Clang 是实际报错主体，它内置了错误计数器和熔断机制：
-
-ferror-limit=N：设为0表示不限制；设为正整数（如5）表示最多报告 N 个错误，之后停止诊断并退出 - 该选项影响所有错误类型（语法、类型、未定义行为等），但**不影响警告**（
-W系列） - 错误计数包含模板实例化展开后的所有子错误，可能比肉眼看到的“明显错误”多得多
- 即使用了
-ferror-limit，Clang 仍可能在达到阈值前因严重错误（如内存耗尽、IR 构造失败）提前崩溃
为什么不能靠 llc 或 opt 限制报错
这些是 LLVM 后端和优化工具，运行在 IR 已生成的前提下：
-
llc报错通常意味着 IR 不合法（如类型不匹配、未定义指令），此时已过了前端阶段，-ferror-limit失效 -
opt报错多因 Pass 冲突或 IR 验证失败（如verify-function检出 malformed IR），这类错误无法用前端参数压制 - 试图用 shell 截断
llc输出（如2>&1 | head -n 20）只会隐藏问题，不阻止编译流程继续或生成损坏的机器码
常见误操作与真实效果
很多人试过这些方法，但基本无效：
-
-Werror：把警告转错误，**增加**而非减少错误数 -
-fsyntax-only：只做语法检查，不改变错误上限 -
clang -x c /dev/null 2>&1 | head -30：仅截断终端输出，Clang 进程仍会完整跑完所有诊断逻辑，甚至更慢 - 修改
DiagnosticOptions源码重新编译 Clang：可行但极不推荐——每次升级 Clang 都要重做，且容易破坏诊断上下文连贯性
真正关键的是：错误数量本身不是问题，**密集报错往往说明前置错误（如头文件缺失、宏定义错乱）引发了连锁推导失败**。与其压数量，不如先解决第一个 error: 行——后面九成错误会自动消失。
