Choosing an AST to develop a static code analyser for Elixir? Core Erlang or Expanded Elixir AST?

Hi,

We are hoping to develop a static code analyzer for Elixir in order to detect concurrency issues (mainly deadlock and race conditions). We have some basic idea about the structure for the analyzer, but our problem is which AST would be better suited for this task. As we have understood the Elixir compilation process creates an Expanded Elixir AST, Abstract Erlang Format and Core Erlang.

My question is out of these whether the Expanded Elixir AST or Core Erlang would be better for creating the Call Graph and Control flow graph. And if we use Core Erlang is it possible to work our way backwards from Core Erlang to find the source within the Elixir code for the issues identified by the analyzer?

If anyone has some idea about this, your help would be really appreciated. :slight_smile:

2 Likes

This is really perplexing to me. Of all languages and runtimes you are worried that Erlang/Elixir will deadlock? :open_mouth:

What kind of deadlocking scenarios you have unveiled while working with Erlang or Elixir?

1 Like

A genserver calling itself deadlocks. A pool with bad logic around checking connections in and out can lock. etc.

3 Likes

I see. Well, that’s a programmer error that’s really easy to avoid on the BEAM. While using classic mutexes, condition variables, semaphores, and having to deal with spurious wakes etc., having an analyser would make much more sense. On the BEAM detecting those things is kind of… strange.

1 Like