Dialyzer Diagnostics

[scohen]

This is a big feature, but we should start small

Dialyzer creates files called persistent lookup tables or .plts. These tables are extremely specific to code. We should generate .plt files for

1. The erlang release
2. The elixir release
3. Your application's code

I believe these tables can be updated via code, but we need to be extremely careful about when we do so and how we do so. They're effectively caches, and caches are evil. This is also an area where elixir_ls doesn't do so well, and one of the reasons why deleting your .elixir-ls directory is the way to fix problems.

So to start small, we should create a dialyzer subdirectory in .elixir-ls and in that directory, store various .plt files. These files will need to be named after the elixir and erlang releases they index.

Then we need to create a plt for our app. This is going to be tough, since the code there changes so much. I'm wide open to ideas, but we should probably walk the module tree when we compile the first time and keep md5s of each module. Then, when a module is compiled, we need to write the md5 to the cache, and update that module in dialyzer.

[scottming]

Regarding whether a module is stale or not, elixir compiler has an implementation

[Moosieus]

OTP 26 added an incremental mode to Dialyzer that makes syncing the lookup tables a lot less painful. That given, I think an effort to add Dialyzer to Lexical would be best served by only enabling it for OTP 26 and forward.

[scohen]

Why not just use dialyxir?

[scohen]

My perspective is that lexical's namespacing allows us to use libraries like dialyxir in remote control. This would confer the following benefits:

• we'd use the project's configs and plt files
• the error messages are improved
• we don't have to build the infrastructure to do all the dialyzer stuff
• it's likely easier to add incremental mode to dialyxir than to build dialyzer support from the ground up.
• We'd help another project (and one we use)