#Clippy lints
79 messages · Page 1 of 1 (latest)
pedantic is a good set that isn't too bad
(i.e. clippy::pedantic)
also don't forget about the builtin lints
#![warn(missing_debug_implementations)]
#![warn(missing_docs)]
#![warn(noop_method_call)]
#![warn(trivial_casts)]
#![warn(trivial_numeric_casts)]
#![warn(unreachable_pub)]
#![warn(unused_import_braces)]
#![warn(unused_lifetimes)]
#![warn(unused_qualifications)]
not a clippy lint, but be sure to enable #![warn(rust_2018_idioms)], which sadly isn't warn-by-default currently
I like the builtin lint deny(unsafe_op_in_unsafe_fn)
#![deny(rust_2018_idioms)]
#![warn(clippy::cast_lossless)]
#![warn(clippy::exhaustive_enums)]
#![warn(clippy::exhaustive_structs)]
I like having to actually scope unsafe operations, and also unsafe in a fn signature should be about the api and unsafe {} blocks should be the operation
oh hey I reviewed clippy's lints for things I wanted to turn on, but never took a hard look at the builtin lints — thanks for the idea.
I'd add explicit_outlives_requirements to this list
as well as clippy::pedantic I also use clippy::wrong_pub_self_convention
wait, that's not a thing anymore?
right yeah, seems it was merged into clippy::wrong_self_convention, nice
Is this for the 2021 edition?
it's things for the 2018 edition
like things that were added/deprecated there compared to 2015
Cool. Is there one available for 2021?
2021 didn't deprecate any language features in the same sort of way
Are there some clippy lints people turn off? Like I don't like the ones that insist you use char literal instead of a str literal. That's just annoying and pointless.
not counting case-by-case,
#![allow(clippy::collapsible_if)]
#![allow(clippy::collapsible_else_if)]
#![cfg_attr(test,
allow(clippy::float_cmp), // Tests work with predictable floats
allow(clippy::redundant_clone), // Tests prefer regularity over efficiency
)]
Oooh, allowing lints specifically for all tests make a lot of sense.
I don't like collapsing ifs when the algorithm I'm trying to express is very specifically "check for A, and only if that's true, compute B, and if that did something, …"
yeah encoding logic in short circuiting can sometimes be tricky
also in the case of
if case_a_not_b {
// Case A
handle_case_a();
} else {
// Case B
if condition_in_case_b() {
handle_case_b_nontrivial();
}
}
I prefer a more symmetric if-else over making that an if-else-if, but collapsible_else_if doesn't like that style
I also have a pet peeve about the overstated advice "floats are imprecise!!! never compare floats exactly!!!!!!!!!!!" but not quite enough of one to disable that one globally
I thought this was gonna become warn by default on 2021 edition
According to the docs, some of the lints in that are warn by default but some aren't https://doc.rust-lang.org/nightly/rustc/lints/groups.html
Do I have to enable this lints in the code? Or can I throw them in a file like clippy.toml?
Wow, I added
#![warn(
clippy::all,
clippy::restriction,
clippy::pedantic,
clippy::nursery,
clippy::cargo
)]
to the beginning of a project and clippy generated 600 warnings.
and how many of them were useful?
Including the warning that tells you not to #![warn(clippy::restriction)] I'm assuming
most of them were about using non ASCII literals
and changing them to utf byte code or soemthing
not a chance thats an improvement
There's a reason it's in the restriction category 
The restriction category also warns against not using return at the end of function bodies
it's not really meant to be used
yeah, I didn't know restriction was so extreme
it is sort of just for people who don't like rust idioms I guess
pretty much
it's for people who don't like specific parts of rust and who have some reason to forbid them
like
the one about not using integer arithmetic
is a pretty useful one
in specific circumstances
how is that?
?clippy
#![forbid(clippy::integer_arithmetic)]
fn _foo() {
let x = 2;
let y = 255;
let _z = x + y;
}
error: integer arithmetic detected
--> src/main.rs:6:12
|
6 | let _z = x + y;
| ^^^^^
|
note: the lint level is defined here
--> src/main.rs:1:11
|
1 | #![forbid(clippy::integer_arithmetic)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#integer_arithmetic
error: could not compile `playground` due to previous error
using fallible functions?
it's about integer overflow
I see
i used it recently to basically go "okay, show me all the places i can overflow"
and then i manually went through and inspected all of them
the folks at linux would appreciate that if they ever pick up rust.
and went "okay this overflow can't happen, this one can't happen, this one can"
it's not really to be used globally
yeah, that can be extremely useful
but if you've been having problems with integer overflow
getting the compiler to output a nice list of every thing that might be a source of an overflow
is useful
Is the overflow possibility because rust picks the lowest size for each literal while doing type inference?
Does it happen if you do let x : u32 = 2;?
running clippy::pedantic on my project
getting tons and tons of docs for function returning Result missing # Errors section for internal functions

they are really pedantic
binding's name is too similar to existing binding
didn't know it did that
warning: unnecessary structure name repetition
--> amqp_transport/src/methods/mod.rs:46:23
|
46 | let mut vec = Vec::with_capacity(len);
| ^^^ help: use the applicable keyword: `Self`
|
I can see why this is nursery
i just happen to not be alloc
and not implementing Vec
but understandable that clippy would think I am
warning: item name ends with its containing module's name
--> amqp_transport/src/error.rs:5:42
|
5 | pub use amqp_core::error::{ConException, ProtocolError};
| ^^^^^^^^^^^^^
|
= note: `-W clippy::module-name-repetitions` implied by `-W clippy::pedantic`
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#module_name_repetitions
wow clippy, thank you
Hehe, kinda like that one tho. With Error being an obvious exception
protocol::Error > ProtocolError
O_o
Interesting... I wonder if there's an equivalent for possible out-of-bounds indexing