re-publishDiagnostics after didOpen

[ia0]

rust-analyzer seems to only publishDiagnostics at startup and when the code changes. It seems other LSP servers like clangd additionally publishDiagnostics after didOpen. This saves LSP clients to store diagnostics for files that are not open.

What is rust-analyzer opinion about this? Should rust-analyzer support such (possibly optional) feature?

For context, eglot (the builtin LSP client implementation of Emacs) relies on LSP servers to publishDiagnostics after didOpen. I've opened a bug on their side too, ideally such that rust-analyzer can meet eglot somewhere: joaotavora/eglot#1531 (contains reproduction steps).

[ShoyuVanilla]

I believe this should be doable in rust-analyzer without too much trouble, though I’m not very familiar with idiomatic practices of LSP.
@davidbarsky, I’d appreciate your thoughts on this.

[ia0]

How should we proceed if we don't get an answer? Should we try to find someone else? (maybe from clangd)

[ShoyuVanilla]

That might help. I’m not sure what other rust-analyzer team members or contributors think, but gathering concrete implementation cases could make it easier to persuade them. I’d also like to explore more cases myself, though at the moment we’re focused on migrating to rustc’s new trait solver, so other tasks are a lower priority right now.

[ia0]

though at the moment we’re focused on migrating to rustc’s new trait solver, so other tasks are a lower priority right now.

Sounds good, thanks!

FYI the code for clangd is here, which will eventually publishDiagnostics (asynchronously) after didOpen.

[ShoyuVanilla]

Thanks! I'll check clangd and other famous lang servers

[davidbarsky]

Oh crap, sorry: I didn't see the @ notification at all. I don't know why I don't get those from GitHub anymore. Anyways, I don't think we need a feature flag, but I don't see why can't republish publishDiagnostics after a textDocument/didOpen, especially if we have those diagnostics stored in-memory. However, I need to remind myself of a few things.

Note that clangd is a bit different than rust-analyzer architecturally; it's much closer to RLS of yore than to rust-analyzer today, in that it doesn't have a split between "native" diagnostics and compiler-sourced diagnostics—all diagnostics from clangd are from the compiler.

To reference the linked conversation on eglot:

There's a new "pull diagnostics" model though, where the client explicitly requests them. But few servers implement this

We implement pull diagnostics in rust-analyzer for rust-analyzer's "native" diagnostics, but rely on push diagnostics for diagnostics from rustc. Not sure how to fix this most reasonably, but these are my current thoughts.

[ia0]

Thanks! (Note that in my case, I only care about diagnostics from rustc if it simplifies anything.)