add options and documentation for diagnostics

[BurntSushi]

Some of my code has been untouched for quite some time, and thus, doesn't always follow the latest conventions, such as using short-hand struct initialization. I have a lot of code to maintain, and updating all of it to adhere to these conventions is very time consuming. This is generally why I avoid Clippy (among other reasons, like there being too many false positives), and also why I occasionally squash deprecation warnings.

It seems like rust-analyzer has its own lints that it provides, seemingly called "diagnostics" in the source code, but I cannot figure out how to disable them. In particular, I have some code that is not using shorthand struct initialization everywhere, so rust-analyzer warns at every such instance, which is quite annoying.

It took me quite some to figure out where this warning was coming from. At first, I thought rust-analyzer was somehow embedding Clippy. And then I thought perhaps the compiler was emitting this warning (strange as that might be) and that I had somehow squashed this warning in the normal cargo build workflow in a way that wasn't getting picked up by rust-analyzer.

It wasn't until I grepped the rust-analyzer source code that I realized it was the one responsible for the warning.

I was pretty surprised by this, and generally did not expect rust-analyzer to also be a linter. Is it intended for rust-analyzer to stand up its own linting strategies separate from Clippy?

It would be very nice to have some docs on this and also a way to turn it off. In particular, if I run cargo build in my terminal and that exits cleanly, then I generally expect rust-analyzer to be similarly clean.

[matklad]

Yes, rust-analyzer, packs a number of its own lints, and, long term, should merge with clippy as well, for two reasons (which will be true "in the limit", but don't necessary hold today):

• rust-analyzer can provide better automated fixes
• rust-analyzer linting can be real-time, because it can only lint code in the currently opened editor.

It's true that the docs for some of our lints are missing at the moment. There's https://github.com/rust-analyzer/rust-analyzer/blob/master/docs/user/features.md which lists most, but not all, features.

It's also unfortunately true that there's no way to toggle this off at the moment :( One of my personal design wishes for rust-analyzer is to have feature flags for every feature, but that hasn't been implemented yet.

However, I think in this particular case the root cause might slightly different. This diagnostic has WeakWarning severity (which corresponds to the Hint level from LSP), and the semantics of this level should match your use-case. Specifically, WeakWarning is for things that:

• are totally OK to have in the code
• don't need to be fixed proactively
• can be avoided in the new code
• can be fixed if you touch the old code anyway

In particular, VS Code renders them with a very short and subtle wavy underline:

and these warnings do not participate in problems list and "go to next problem" action.

So, if you editor renders these diagnostics in such a way that makes you feel like you should fix them, or that interacts with your workflow, the problem could be with the editor.

But, anyway, we should fix docs and implement feature flags regardless.

Also, I should say I really appreciate your thorough experience reports, that's really helpful!

[matklad]

To expand a little bit on the motivation for WeakWarnings: they are devised exactly to solve "linting fatigue". There are cases where you don't want to proactively fix things (b/c there's a lot of existing code) or there are "false positive" (or positive/negative is not applicable at all, and this is more of a "tastes" or "context" thing).

For this cases, IDE can show you (in an easy-to-ignore way) auto-applicable suggestions only for the code you are looking at, which is a good proxy for "new, or modified old code". Actually, I think in vim's case it might be cool to try to show these things only when in insert mode, so as not to distract usual browsing.

[BurntSushi]

Ah okay, so to make this concrete, I'll show some screenshots. vim does show "weak" warnings as things that are a bit lighter than normal errors:

And here's a normal compilation error:

In my view, even though the weak error is a different style, it's still calling out to me to fix it. I generally do not want to see anything like this if it corresponds to a problem that I don't want to fix. Even if I were using VS Code, those light-bulbs would drive me crazy. :-) I would absolutely still be looking for a way to disable them. I like your wording, "lint fatigue," because that's exactly what I'm feeling here. To be honest, there is no visual indicator of a weak warning that I would be okay with just leaving there. My eyes would see it and I'd still want it either fixed or ignored.

Your comments about this being a visual issue prompted me to check if ALE (my LSP client) could squash these on its end. But it seems that it can't, and that the suggested approach is to configure the underlying tool (in this case, that would be rust-analyzer). I'm not sure whether this philosophy is shared by other LSP clients, but I wouldn't be surprised if it was. It seems reasonable to force configs like this to be done in the tools themselves.

In this particular case, I'll probably just fix the short-hand struct initialization, but if this were a warning I didn't want to fix (e.g., because of MSRV concerns), then this would probably be a strong blocker preventing me from using rust-analyzer unfortunately.

[matklad]

I would absolutely still be looking for a way to disable them.

100% understand you there, "not being able to disable a feature" is something I myself is regularly annoyed with. I hope to get to fixing this sooner rather than later :)

[DJMcNab]

This is related to the issue that we need to correctly have per-file configuration, as that is the specificity the protocol allows.

Additionally, rfc 2103 seems relevant for the middle-long-term of this.

[BurntSushi]

@matklad This is turning out to be a bigger issue to me than I thought it would be. I spend a lot of my time reading code, not necessarily code that I wrote or maintained, and not necessarily code that has been written with the latest conventions. The extra linting that rust-analyzer is doing (combined with high latency goto definition) made me switch back to RLS. Would you accept a PR that resolved this issue in the simplest possible way? e.g., Provide a way to completely disable all extra lints done by RA?

[DJMcNab]

I'm sure he would. We already have settings to disable e.g the typing and highlighting features.

[matklad]

Sure, I think the bits of the simplest solution (besides just commenting out the relevant bit of code in ra itself) are: * add a config for this ( deea8f5 done this for exclusions) * change `handle_diagnostics` function in handlers.rs to do nothing if the option is set

…

On Fri, 16 Aug 2019 at 15:19, Daniel McNab ***@***.***> wrote: I'm sure he would. We already have settings to disable e.g the typing and highlighting features. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1653>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANB3M32WO6FCGJJ7DPAUPDQE2LMHANCNFSM4IJPYZKA> .

[matklad]

#1715 implements the feature flags infra, as well as lsp.diagnostics flag which should disable all diagnostics. Documenting everything and adding flags to other features is yet to be done

[BurntSushi]

@matklad It looks like you implemented a way to turn of diagnostic lints like this via lsp.diagnostics, but I have no idea how to actually set it. I'm use ALE in vim as my lsp client, and it appears to have a way to set config options, but no permutation of things I've tried have worked. e.g.,

let g:ale_rust_rls_config = {
      \ 'feature_flags': { 'lsp.diagnostics': 0 }
      \ }

Is something like this intended to work, or is there more infrastructure that needs to be built in order to disable lints like this?

[matklad]

I would think so, though we don't have ale config documented yet (docs for other vim plugins) so it's hard for me to tell.

[nmahendru]

@BurntSushi got that ALE config to work ? I am also looking for that in case you got it to work.

[BurntSushi]

@nmahendru I was unable to get ALE and RA to work like I wanted, but I no longer remember the problems. I took that opportunity to switch nvim and use its native LSP support, but I couldn't get that to work either. So I caved and started using CoC. That seems to work well. See https://github.com/BurntSushi/dotfiles/blob/08852db5826d4e0c51c49e1dec6a75c5d3f53323/.config/nvim/include/plugins.vim#L32 and https://github.com/BurntSushi/dotfiles/blob/08852db5826d4e0c51c49e1dec6a75c5d3f53323/.config/ag/nvim/coc-settings.json

[iagox86]

Hey, I landed hear searching for a way to customize the built-in linting from rust-analyzer. The "shorthand struct initialization" warnings are driving me crazy.. I don't like shorthand initialization, and I also don't like warnings on my code.

I haven't seen a resolution in this issue, so maybe this is the wrong place, but: is there some way to just disable that specific check? I see rust-analyzer.diagnostics.disabled as a configuration option, but I can't find a name for check_struct_shorthand_initialization so I'm at a loss. I've been reading rust-analyzer code for over an hour, and I give up.

Is there some way to disable just that exact check?

[matklad]

@iagox86 no, at the moment there's no way to disable that specific diagnostic. It is a desirable feature, but it is not yet implemented (although the ground work was put in place since the issue was originally opened). The fix should go around here. Note that we already check for config.disabled.contains for most diagnostics except the two hints above.

Note also that this is not a "warning", but a "hint" -- semantically, this is not something you need to fix, and we flag it as such at the protocol level. So, there might also be couple of fixes on the client side:

• these should be rendered significantly less conspicuous than warnings
• the client could have "show hints" setting to suppress display of all hints.

[iagox86]

FWIW, I'm using neovim with the new-ish built-in LSP support. It doesn't seem to be especially configurable, though I imagine over time things will improve there. I couldn't find a way to squash hints, although I'm not sure I'd want to squash all hints anyways.

Thanks for the info! I'll keep my eye on things here.