Allow enabling clippy for an entire workspace

[Nemo157]

The current clippy opt-in detection requires annotating every crate with #![warn(clippy::all)], when you have a larger workspace that is forcing clippy compliance this is quite a bit of overhead (and can be annoying if you forget to add it to a new crate). If you are also checking every target I assume this will require every bin and test file to be annotated as well (I haven't actually tested that this is the case).

It would be nice if it were possible to add something to the workspace toml telling RLS to enable clippy on all crates, along with a flag telling it whether to run on all targets or not.

[alexheretic]

Turn it from opt-in to on. See rls#configuration.

[Nemo157]

@alexheretic that requires editor specific configuration, and if a user is manually setting clippy_preference: off in their global config for whatever reason I wouldn't want a project-specific config distributed in the repository to override this. What I'm looking for is a way to annotate the workspace as a whole as using Clippy for when users are using clippy_preference: opt-in and having RLS know that no matter how it is launched.

One idea I just had was that existence of a Clippy config file (clippy.toml/.clippy.toml) could be another indicator for opt-in activation. That could be overly aggressive if someone has a workspace where they only run Clippy on a subset of crates but want to configure it for those crates, but that situation seems unlikely.

[alexheretic]

Global config is a client concept each RLS process can be configured without affecting each other. So if your client cannot set clippy_preference per-project it's an issue with the client.

However, I thought vscode (which is what I assume is relevant) allowed per-project config. ide-rust allows this with rls.toml files.

In a client a project specific config overriding a global config is the right way of doing it right?

[Nemo157]

I thought vscode (which is what I assume is relevant) allowed per-project config

It does, but I'm not directly caring about any specific editor for this. I don't want to be distributing config files for all of VS Code, Atom, ALE, Eclipse, Kakoune, etc. in my projects repository. RLS itself is such a fundamental Rust development tool that I would feel much better being able to directly configure it for the project.

In a client a project specific config overriding a global config is the right way of doing it right?

But if we were to distribute an editor config file in our project repository this would be the case of a project's default project config overriding a user's custom global config, it makes sense that a user's custom project config should override their custom global config, but if the user is turning Clippy off for some reason I don't want to force them to enable it in a project I maintain (which is one reason I really like that RLS defaults to opt-in instead of requiring the editor itself to choose on or off, I just wish that there were a way for a larger project to more aggressively opt-in than having to do so in each individual crate).

[alexheretic]

Rls moved away from a common config source instead it's up to clients to provide config.

As a result what you want isn't really possible. Practically rls config is up to the user only.

Of course you can add #!warn to all your crates, but I agree this isn't ideal with larger workspaces.

Perhaps switching rls config to directly reading hierarchical rls.toml files would better address this issue.

[norru]

It does, but I'm not directly caring about any specific editor for this. I don't want to be distributing config files for all of VS Code, Atom, ALE, Eclipse, Kakoune, etc. in my projects repository. RLS itself is such a fundamental Rust development tool that I would feel much better being able to directly configure it for the project.

I cannot agree more.

@mickaelistria FYI