We are hoping to develop a static code analyser for Elixir in order to detect concurrency issues (mainly deadlock and race conditions). We have some basic idea about the structure for the analyser, 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 analyser?
If anyone has some idea about this, your help would be really appreciated. :)
If the purpose is educational I would probably go with erlang. The compiling of erlang to beam will probably be a little more straightforward (if not a lot more) and as you develop your tool, you will probably find more resources/documentation on erlang ASTs. It's lower level than what most people do and you'll find more answers in the erlang community (probably won't be true in a few years). Overall, your tool would be simpler in erlang, with less moving parts.
I also found that project : https://github.com/rrrene/credo
More specifically, I think it will be practically difficult to work you way back to elixir code. From your perspective, after having implemented your tool, it will make sense. But that probably would not be the case for your average elixir developer. The more elixir matures, the more it tends to depart from core erlang concepts. It builds a lot of features on top of erlang, to the point where you can build entire web applications without knowing a single bit of erlang. Probably not the best approach but the fact that it's possible tells you how large the gap between the two languages can become.