feature request: diagnostics

[cfbender]

What would you like to see?
A diagnostics functionality to the LSP, to see compiler errors in-editor.

Why?
Typos and things like unused variables can be nice to see

I understand the idea of dexter is to not compile for most functionality, so I think it would be useful to have it as an asynchronous process where the compiler is run outside of the main parsing.

I have an implementation I'm playing around with on https://github.com/cfbender/dexter/tree/feat/diagnostics that seems to be working well so far - but I didn't want to PR it in order to have a discussion first on the feature if it's something y'all are interested in, and then maybe a better implementation than this

[JesseHerrick]

Hey @cfbender, I love the idea! We actually already do a little bit of diagnostics from the formatter, so I think that the Elixir sidecar approach can work really well.

Here are some things that I think we'll need to consider when building this:

• What are the most important diagnostics people want to see? Is it just unused variables and functions? Anything else?
• If my project has 10,000 files and I just upgraded Elixir, I might not want the LSP to be doing the compilation for me because it's not very transparent and it could continually timeout. In this case, if we have a timeout of 60 seconds, the LSP might not actually finish compiling in time and end up restarting over and over again without ever finishing the compilation. At the same time, it would have a lock on compilation, so we'd be unable to compile directly using mix compile either.
• How do we get maximum speed out of this? As we saw with the formatter, running via mix compile directly is probably the slowest way that we could do this. It would be better if we can start up an Elixir sidecar server like we do for the formatter and have it handle the formatting.
• What is the optimal timeout here?
• Do we apply diagnostics to all files that have warnings with compilation?

There are probably more questions I haven't thought of yet. So, I'm absolutely onboard with exploring this and would welcome a PR. However, it's paramount that any solution that we have considers enormous codebases that take > 10 minutes to compile entirely.

[cfbender]

I think unused variables or non-existing variables/functions would be a great start. With the type system growing in capability, I think type errors should definitely be present at some point as well.

I think you've made some great points, and I may explore the sidecar server approach on my branch to see what it's like. right now for our project (~2200 files, ~100k LOC of elixir without tests) I am seeing about 5-6 second incremental compiles for the mix compile approach, which to me is definitely unacceptable in the long-term. Please let me know if you have any more thoughts and I can update here if I come up with anything I think really works!

[cfbender]

okay @JesseHerrick I've done a fair bit of exploration, and ended up rebasing onto your tokenizer branch which has made it much easier to get performant diagnostics. I have undefined variable function implemented on that branch, and it's currently what feels like sub 100ms on a large repo which is a huge improvement (haven't actually timed it yet).

it's seeming like that is likely the easiest way forward since you're doing the work to parse/lex, and I think fits well with the project. the code needs a fair bit of cleanup but I could target it as a PR eventually if you're interested.

I do think the elixir sidecar could work as well - in the project I'm testing we have a fair bit of xref problems that slow the compile down, so that's maybe a bigger issue for now. I think it would just be tough to approach parity in diagnostics with mix in this case