c - GCC 和 Clang 解析器真的是手写的吗？

Question

似乎 GCC 和 LLVM-Clang 使用的是手写递归下降解析器，不是机器生成的、基于 Bison-Flex 的、自下而上的解析。

这里有人可以确认是这种情况吗？如果是这样，为什么主流编译器框架使用手写解析器？

更新:interesting blog on this topic here

Answer 1

有一个民间定理说 C 很难解析，而 C++ 基本上是不可能的。

这不是真的。

事实是，C 和 C++ 很难使用 LALR(1) 解析器进行解析，而无需破解解析机制和纠缠在符号表数据中。事实上，GCC 曾经使用 YACC 和其他像这样的 hackery 来解析它们，是的，它很丑陋。 现在 GCC 使用手写解析器，但仍然使用符号表 hackery。 Clang 人员从未尝试过使用自动解析器生成器；据我所知，Clang 解析器一直是手工编码的递归下降。

事实是，C 和 C++ 相对容易用更强大的自动生成的解析器解析，例如 GLR parsers ，而且您不需要任何技巧。 Elsa C++ 解析器就是其中一个例子。我们的C++ Front End是另一个(就像我们所有的“编译器”前端一样，GLR 是非常棒的解析技术)。

我们的 C++ 前端不如 GCC 的快，而且肯定比 Elsa 慢；我们没有投入多少精力仔细调整它，因为我们还有其他更紧迫的问题(尽管它已被用于数百万行 C++ 代码)。 Elsa 可能比 GCC 慢，因为它更通用。考虑到如今的处理器速度，这些差异在实践中可能并不重要。

但是今天广泛分布的“真正的编译器”的根源是 10 年或 20 年前或更早的编译器。那时效率低下更为重要，而且没有人听说过 GLR 解析器，因此人们按照他们知道的方式去做。 Clang 肯定是最近才出现的，但是民间定理在很长一段时间内都保持着“说服力”。

您不必再这样做了。您可以非常合理地使用 GLR 和其他此类解析器作为前端，同时提高编译器的可维护性。

是的事实是，很难获得符合友好社区编译器行为的语法。虽然几乎所有的 C++ 编译器都实现了(大部分)原始标准，但它们也往往有很多暗角扩展，例如 MS 编译器中的 DLL 规范等。如果你有一个强大的解析引擎，你可以花时间尝试使最终语法符合现实，而不是尝试改变语法以符合解析器生成器的限制。

2012 年 11 月编辑:自撰写此答案以来，我们改进了 C++ 前端以处理完整的 C++11，包括 ANSI、GNU 和 MS 变体方言。虽然有很多额外的东西，但我们不必更改解析引擎；我们刚刚修改了语法规则。我们确实必须改变语义分析； C++11 在语义上非常复杂，这项工作淹没了让解析器运行的努力。

2015 年 2 月编辑:...现在可以处理完整的 C++14。 (请参阅 get human readable AST from c++ code 了解一些简单代码的 GLR 解析，以及 C++ 臭名昭著的“最令人烦恼的解析”)。

2017 年 4 月编辑:现在处理(草案)C++17。