feature request: diagnostics #29

Activity

1. cfbender

   added

   enhancementNew feature or requestNew feature or request

   on Apr 13, 2026
2. JesseHerrick commented on Apr 14, 2026

   

   JesseHerrick

   on Apr 14, 2026

   Member

   More actions

   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.

   👍React with 👍1Reacted by Brett
3. cfbender commented on Apr 14, 2026

   

   cfbender

   on Apr 14, 2026

   Author

   More actions

   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!
4. cfbender commented on Apr 15, 2026

   

   cfbender

   on Apr 15, 2026

   Last edited by cfbender

   Author

   More actions

   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