stable clippy.toml: Create RFC #15630
Conversation
|
|
d64c47e to
e5a9868
Compare
This PR creates a public RFC for how clippy.toml should be handled. I made some improvements to some parts of the system. These are better to get fixed today than to wait until someone has a problem with them and then have to make a breaking change. Based on Philipp's RFC. This would be the first stage of 3 to completely stabilize clippy.toml
e5a9868 to
fb11b83
Compare
|
@ojeda Is this more or less what you need? The RFC stabilizes the existence of the Clippy configuration file, the algorithm to find it, the existence of The only thing needed apart from this would be stabilizing the configuration options themselves. Which, because of your usecase, the first ones will be |
|
Thanks for working on this!
That would be great. It may be good to mention in the RFC what would be the "stable mode" -- IIUC it would fail on unknown keys (like Clippy today), but it would not allow to use unstable keys (unlike Clippy today). Is that correct? If so, then does that mean that unless all those options (
If Clippy plans to support that eventually, then an alternative would be to not stabilize the file and go for flags directly -- for us it would make it easier to pass flags to Clippy depending e.g. on the version. But, of course, that would open again the questions about how to pass all what the TOML allows for non-trivial keys. IIRC we discussed it in Zulip a while ago. |
The problem with this is passing complex values to the flag. That's why this RFC changes I can see that this approach has some ergonomic issues, but it's not that different than having to maintain different CLI flags depending on version. |
|
|
||
| --- | ||
|
|
||
| When `unstable-conf` is not enabled, we are in "stable mode". This means that unknown configuration lints are |
There was a problem hiding this comment.
issue: I really don't want to break existing users of the config this way by requiring them all to opt in here.
Can we see what config options are used by most and stabilize the bulk of them? We can always deprecate/etc.
Is this even necessary for RfL's needs? Last I heard they cared more about the existence of the file being stable rather than the keys themselves.
Alternatively, we can have unstable-conf as an opt out, providing a smooth path for current users as well as a way for people who care about stability to opt in to stable configs.
There was a problem hiding this comment.
We can make it opt-out with unstability being the default (at least for now, until most configuration options are stable)
Can we see what config options are used by most and stabilize the bulk of them?
I'm currently working on a script to do just that, we should have numbers soon
There was a problem hiding this comment.
Yes, that makes sense to me. And we can define a process and criteria for stabilization too.
There was a problem hiding this comment.
I opened #15821 so we should give priority to msrv, too-many-arguments-threshold, type-complexity-threshold, doc-valid-idents, disallowed-methods which are the ones with over 600 projects using them.
This PR creates an RFC for how clippy.toml should be handled. I made some improvements to some parts of the system. These are better to get fixed today than to wait until someone has a problem with them and then have to make a breaking change.
Based on Philipp's RFC. This would be the first stage of 3 to completely stabilize
clippy.tomlBeing that Philipp is on vacation, I'm not sure who could review this, it's a team-wide thing anyways.
changelog:none
Rendered