现代语言是否仍使用解析器生成器？

我是研究关于gcc编译器套件在维基百科这里，当这想出了：

GCC开始使用由Bison生成的LALR解析器，但后来逐渐切换为手写递归下降解析器。2004年用于C ++，2006年用于C和Objective-C。目前，所有前端都使用手写递归下降解析器

因此，在最后一句话中，（以及我所信任的维基百科），我可以肯定地说：“ C（gcc），C ++（g ++），Objective-C，Objective-C ++，Fortran（gfortran），Java（gcj）， Ada（GNAT），Go（gccgo），Pascal（gpc），... Mercury，Modula-2，Modula-3，PL / I，D（gdc）和VHDL（ghdl）”都是前端，不再使用解析器生成器。也就是说，它们都使用手写的解析器。

我的问题是，这种做法无处不在吗？具体来说，我在[Python，Swift，Ruby，Java，Scala，ML，Haskell]中寻找x的“ x的标准/官方实现是否具有手写的解析器”的确切答案？（实际上，这里也欢迎提供其他语言的信息。）我敢肯定，经过大量的挖掘，我可以自己找到它。但是，我也相信社区很容易对此负责。谢谢！

AFAIK，GCC特别使用手写解析器来改进语法错误诊断（即，在语法错误方面提供有意义的人性化消息）。

解析理论（及其衍生的解析生成器）主要是关于识别和解析正确的输入短语的。但是我们希望编译器针对一些错误的输入给出有意义的错误消息（并且能够在语法错误之后有意义地解析其余的输入）。

同样，旧的旧式语言（例如C11或C ++ 11）（在概念上是旧的，即使它们的最新修订版只有三年之久）也不是完全没有上下文的。对于解析器生成器（即bison甚至menhir）在语法中处理上下文相关性非常困难。

解析器生成器和解析器引擎非常通用。通用性的优点是，在整体方案中，快速构建准确的解析器并使之易于操作很容易。

解析器引擎本身由于其通用性而在性能方面受到影响。任何手写代码总是比表驱动解析器引擎快得多。

解析器生成器/引擎难以解决的第二个方面是，所有真正的编程语言通常都是以非常微妙的方式对上下文敏感的。LR语言是无上下文的，这意味着在定位和环境方面存在许多无法在语法中正确传达的细节。属性语法尝试解决基本语言规则，例如“使用前声明”等。将这种上下文相关性连接到手写代码中是很简单的。