README: Add subsection on running Clippy as a rustc wrapper #6782
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @phansch (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
rust-highfive
added
the
S-waiting-on-review
README.md
Outdated
| Then, to enable Clippy, you will need to call: | ||
|
|
||
| ```terminal | ||
| clippy-driver rustc --edition 2018 -Cpanic=abort foo.rs |
There was a problem hiding this comment.
| clippy-driver rustc --edition 2018 -Cpanic=abort foo.rs | |
| clippy-driver --edition 2018 -Cpanic=abort foo.rs |
also works. This does only work with rustc as a second argument, because the clippy-driver has a hack that removes this.
There was a problem hiding this comment.
I noticed that, but I didn't know it was the preferred way -- that is good to know! I will add a note for that also.
There was a problem hiding this comment.
Changed the title of the subsection to match, too.
There was a problem hiding this comment.
I wouldn't note that, because it is an implementation detail necessary to make clippy work.
The clippy-driver binary is the same as the rustc binary from the user/CLI perspective, just that it runs more lints.
There was a problem hiding this comment.
Done!
What do you mean by necessary? From what I understand, the hack around the second argument isn't be necessary but it is there for cargo clippy, no?
Anyway, I agree the chances of someone hitting that behavior by mistake without intending to do so are very low; however, it is still user-facing behavior. For me, as a user, it is OK if it is not supported but I'd prefer to know about it (and users may still notice via cargo verbose output anyway, like I did, and wonder what is going on).
There was a problem hiding this comment.
It is necessary for cargo clippy to work, yes. It's because cargo for some reason runs clippy-driver rustc, so Clippy has to get rid of the rustc.
It doesn't hurt that adding rustc to the command is possible. But I don't see a reason, why we should advertise it.
(and users may still notice via cargo verbose output anyway, like I did, and wonder what is going on)
If you're interested in that, you could ask why it is implemented like this on Zulip or on other channels. IMO it's the same question as why cargo adds -C extra-filename=-73486377a7462660 to the command.
ojeda
force-pushed
the
readme-as-wrapper
branch
from
22b86b4 to
d7bbda5
Compare
This is useful for projects that do not use cargo. Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
ojeda
force-pushed
the
readme-as-wrapper
branch
from
d7bbda5 to
6b8b43c
Compare
|
@bors r+ Thanks! |
|
📌 Commit 6b8b43c has been approved by |
|
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
|
Thanks to you! Cheers. |
It turns out that is only a workaround intended for `cargo`. The official instructions since PR [1] describe the usage of `clippy-driver`, and they intentionally only cover replacing `rustc` with `clippy-driver` rather than wrapping it, as discussed in that PR. [1] rust-lang/rust-clippy#6782 Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This is useful for projects that do not use cargo.
changelog: README: Add subsection on running Clippy as a rustc wrapper