-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Temporarily downgrade uninlined_format_args
(to pedantic
or nursery
)
#10087
Comments
It seems strange to degrade it for every clippy users, when it’s a RA-issue. The logic would be that they set up a workaround on their side. |
Fair enough. But it seems that may take a while, possibly months, perhaps 2 years at most |
Macros are not the easiest when it comes to static analysis. Moving the lint to I think it'd make sense to keep the lint as |
I would rather not change the group - the lint is already reduced from its maximum capacity (it doesn't inline the mixed cases unless there is a setting enabling it). I would love to help (time permitting) for it to be resolved on RA side .. maybe? Might be an interesting experiment |
Per zulip discussion, we decided not to do this. |
Ok, I'll close the issue for now |
The latest Rust update was incredibly disruptive to my team, as we had to go through 27 different crates in our workspace to turn this off. While this is arguably a shortcoming in |
Hmm, the reason we originally decided against this was that:
It's clearly enough of a problem for people still; we should revisit this. In general Clippy's policy is that needing to put allows in your code is not a huge issue, but I think rust-analyzer is a big enough factor here that we should try to be consistent with it. cc @xFrednet @nyurik @Alexendoo as people who were involved in that decision |
My understanding, which might be incorrect, is that while Rust-analyzer cannot handle inlined arguments yet, it is not directly related to clippy -- i.e. someone can still write code with inlined args, or fix existing code with @jeff-hiner you said you had to change all your crates - did you essentially just add a One thing I obviously cannot measure is the "positive" vs "negative" - i.e. the number of those affected by this issue vs those who benefit from it, but are silent. Rust analyzer is a big player in the community, so we clearly should pay attention to it. One other thing -- if we move it back to pedantic/restricted, I feel it would serve very limited purpose because by the time it rolls out to the users, 99% cases would have been fixed, so it won't have much affect. At the same time, having it on will encourage this issue to be fixed faster in all the relevant tools (I would love to help with that btw). |
I believe this comes down to the "correct" solution being something along the lines of rust-lang/cargo#5034; being able to set lint levels at a workspace level rather than having to set it in multiple individual crates. In the medium term, downgrading to pedantic could be a reasonable mitigation... though since it doesn't really justify a point release on its own, it's likely the earliest such a downlevel would ship would be with 1.68. After the lint's been on for six weeks, most projects will have either disabled the lint or adopted it, so the benefit of the downlevel mitigation is significantly reduced. If the "had" is due to blocking CI on warnings, a. A CI warning gate should be on a pinned toolchain version, so that CI doesn't fail for reasons unrelated to local changes. If r-a lacking support for inlined format arguments is a significant deal that we should be worrying about, then you'd probably also want to enable a restriction lint to forbid them; only using them sometimes is the worst of both worlds. |
@nyurik In our case we gate successful builds on both zero warnings and passing For this specific lint, applying the fix caused the aforementioned issues with rust-analyzer so we needed to opt out for the entire workspace. Definitely rust-lang/cargo#5034 made this a lot more painful than it needed to be. We wound up adding rustflags to both We generally instruct team members to keep their own toolchain updated to stable, and the local VSCode configured to show clippy warnings. This is so that they don't push something that looks clean locally but fails CI. As soon as they updated their Rust version the new lint threw 250+ warnings, all of which need to be either fixed or explicitly ignored. Without a clean local build real warnings get buried in the noise. So you do have to set this locally as well, not just in CI. As for the last point, forbidding inlined format arguments would be fine for consistency, at least in our case. That said we haven't needed it yet because nobody pushing code even knew about them. I personally feel that mandating them via a default breaking lint is too sharply opinionated (especially considering the rust-analyzer break), which is why I'd suggest they fit better as an opt-in pedantic. |
Just for clarity,
I don't disagree that the rust-analyzer limitation w.r.t. inlined format arguments is a motivation to delay raising Rather, I think it should be taken as motivation to raise the priority of rust-lang/cargo#5034 a bit. It was a 2021 clippy roadmap item, apparently. There's also the 3rd party cargo-cranky if you don't mind using a 3rd party interface. FWIW, Embark Studios is using |
An additional concern that affects me is that having clippy warn me to use new things conflicts with trying to keep older MSRV support. Effectively this lint is suggesting I require a new compiler, when the existing code was working perfectly fine. I can add allows, but in the older compiler the lint will be unrecognized. |
You can set an msrv tag in clippy.toml, and clippy won't suggest any lints which require a more recent toolchain version than specified. |
Yep, this has been a solved problem for years, if this lint doesn't support that it is a bug and needs to be fixed |
This lint is aware of the MSRV: rust-clippy/clippy_lints/src/format_args.rs Line 205 in 54e929b
|
Hello all 👋, we (meilisearch) are affected by this issue as well: meilisearch/meilisearch#3434 What's more, we discovered that the The following:
Note that even if we weren't using If this lint could be downgraded to |
@dureuill it seems this was recently fixed, and might not have made it into the release. rust-clippy/clippy_lints/src/format_args.rs Lines 294 to 298 in 8fb0041
It was merged as part of #10126 by @flip1995 in december a month ago, but I can't find the summary, so not even sure if it made it into the release or not. |
Restriction lints are emphatically not for this purpose. The current proposal is
FWIW, clippy is intended to be used with a liberal sprinkling of global and local We're hoping to eventually have a way of doing that from Cargo config, maybe also in a way that lets you say "no lints from versions beyond XXX" without having to restrict fix MSRV |
To sum up up to this point, there are two main issues why this lint causes problems:
The rust-analyzer issue is significant, but might also be moot because
So while I agree this is annoying to those affected (I am partially affected by that too), at this stage I honestly do not see any significant benefit of changing it, unless my reasons are incorrect or incomplete. What do you think? |
I'm not sure if we can rely on this because (a) new projects are still a thing and (b) we can uplift if we really want. There's another argument in this space, that projects really don't like applying (indeed, Clippy cannot exist without this policy: if the entire community were able to come to alignment on a lint, it could reasonably be uplifted into rustc, which has this higher bar.) So in general my reaction is typically "just There's also the effort argument: but I'd like to make clippy.toml happen so that it's never a problem again.
There's a reasonable argument to be made that that should be a restriction lint. I think if someone proposed it we would probably accept it.
It's unclear if this is "sooner" or "later". cc @rust-lang/clippy |
Without even talking about new projects, even new crates in the same workspace are affected by this change and will need to sprinkle more
💯 |
Generally we expect projects like this to standardize lint-allow boilerplate, much like most of them standardize license header boilerplate already. |
I personally don't like those. In |
Yeah, doing it at the CLI level works as well. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
uninlined_format_args
to restriction
(temporarily)uninlined_format_args
(to pedantic
or nursery
)
Opened #10265 I'm not going to push for uplifting this myself, but folks are free to ask upstream to uplift to beta or even a point release; I'm not opposed to doing one. |
3434: Make clippy happy for Rust 1.67, allow `uninlined_format_args` r=Kerollmops a=dureuill # Pull Request This PR allows `uninlined_format_args` in CI for clippy. This is due to rust-lang/rust-clippy#10087, which in particular has correctness issues wrt edition 2018 crates, and is a big change altogether. rust-lang/rust-clippy#10265 is already open in order to change the category of this lint to "pedantic", meaning that if this latter PR merges, a future Rust release will accept our code unmodified wrt uninlined format arguments. As a result, this PR introduces the following changes: 1. Allow `uninlined_format_args` in the clippy command in CI. 2. Use rewind rather than seek(0) 3. Remove lifetimes that clippy deems needless. Co-authored-by: Louis Dureuil <[email protected]>
Mark uninlined_format_args as pedantic Fixes #10087 We should restore this when rust-analyzer support gets better. Worth filing an issue to track.
This is being uplifted in rust-lang/rust#107743 (comment) |
I wanted to let this pass, but I keep seeing this argument and think it's disingenuous. RA uses inline format args because you (and then another drive-by contributor) sent a pull request for it. We merged it knowing full well that rename doesn't work with these, but all in all, we're probably well used-to working around buggy IDE support. Us willing to merge a first-time contributor's work of running Personally, I find the CI breakage everywhere much more annoying, especially since |
3464: Remove CLI changes for clippy r=curquiza a=dureuill # Pull Request ## Related issue Reverts #3434, which was linked to rust-lang/rust-clippy#10087, as putting the lint in the pedantic group [is being uplifted to Rust 1.67.1](rust-lang/rust#107743 (comment)) (my thanks to everyone involved in this work 🎉). ## Motivation - Using "standard issue" clippy in the CI spares our contributors and us from knowing/remembering to add the lint when running clippy locally - In particular, spares us from configuring tools like rust-analyzer to take the lint into account. - Should this lint come back in another form in the future, we won't blindly ignore it, and we will be able to reassess it, which will be good wrt writing idiomatic Rust. By the time this occurs, lints might be configurable through `clippy.toml` too, which would make disabling one globally much more convenient if needs be. ## Note We should wait for the release of Rust 1.67.1 and its propagation to our CI before merging this. The PR won't pass CI before this. Co-authored-by: Louis Dureuil <[email protected]>
Description
Since
format_args_capture
is still not supported by rust-analyzer, suggesting to inline vars is actually a bad idea, because it makes refactoring harder (devs must manually rename vars).I suggest we move it to the
restriction
group while that issue is still open.Version
No response
Additional Labels
No response
The text was updated successfully, but these errors were encountered: