选择 AST 来为 Elixir 开发静态代码分析器？核心 Erlang 还是扩展 Elixir AST？答案

【问题标题】：Choosing an AST to develop a static code analyzer for Elixir? Core Erlang or Expanded Elixir AST?选择 AST 来为 Elixir 开发静态代码分析器？核心 Erlang 还是扩展 Elixir AST？
【发布时间】：2020-07-23 10:03:14
【问题描述】：

我们希望为 Elixir 开发一个static code analyser 以检测并发问题（主要是死锁和竞争条件）。我们对分析器的结构有一些基本的想法，但我们的问题是哪种 AST 更适合这项任务。正如我们所了解的，Elixir 编译过程创建了 Expanded Elixir AST、Abstract Erlang Format 和 Core Erlang。

我的问题是扩展 Elixir AST 或 Core Erlang 是否更适合创建调用图和控制流图。如果我们使用 Core Erlang，是否有可能从 Core Erlang 向后工作，以在 Elixir 代码中找到分析器识别的问题的来源？

如果有人对此有所了解，我们将非常感谢您的帮助。 :)

【问题讨论】：

这是一个题外话。请将其发布到elixirforum.com 以获得更好的反馈。
@AlekseiMatiushkin 非常感谢。我会发布它。
出于好奇，透析器有什么问题？
@user1720740 毫无疑问，Dialyzer 是一个了不起的工具。但在这里，我们正在开发另一种工具，仅用于教育目的。实际上要了解静态代码分析器的内部结构。
@hackerbuddy 我明白了。真是个好主意。我将尝试发布答案。广泛的问题，模糊的答案，对不起。但我知道你来自哪里。

标签： erlang elixir abstract-syntax-tree static-code-analysis coreerlang

【解决方案1】：

如果目的是教育，我可能会选择 erlang。将 erlang 编译为 Beam 可能会更简单一些（如果不是更多的话），并且随着您开发工具，您可能会发现更多关于 erlang AST 的资源/文档。它比大多数人所做的要低，您会在 erlang 社区中找到更多答案（几年后可能不会是真的）。总体而言，您的工具在 erlang 中会更简单，移动部件更少。

我还发现了那个项目：https://github.com/rrrene/credo

更具体地说，我认为让你回到 elixir 代码实际上是很困难的。从您的角度来看，在实现您的工具之后，这将是有意义的。但对于普通的 elixir 开发人员来说，情况可能并非如此。长生不老药越成熟，它就越倾向于偏离核心的 erlang 概念。它在 erlang 之上构建了许多功能，以至于您可以构建整个 Web 应用程序而无需了解一点 erlang。可能不是最好的方法，但它可能告诉您两种语言之间的差距有多大。

【讨论】：