Most commonly ignored lints on crates.io #7666
Comments
rustbot
added
A-category
|
This is an extremely helpful metric and it certainly lends itself to some specific changes. Thank you @dtolnay for all the work you've put in to making Clippy less annoying. 😃 |
|
The top 2 most widely suppressed lints, whether you look at global or local, are We should also collect info on the
|
When I looked at the list, I also thought that by today's standards we'd probably place this lint in I don't have a strong opinion about |
|
For the rest, I think dtolnay/noisy-clippy#1 is gonna be a blocker for further action on a lot of them. We need a way to browse what is going on at each of these suppression sites. I'd call out that I'm guessing
|
Downgrade many_single_char_names to pedantic As suggested by `@flip1995` in #7666 (comment), by today's standards this lint would be considered `pedantic`. This is one of the most widely suppressed Clippy lints on crates.io according to https://github.com/dtolnay/noisy-clippy. In my opinion this lint is just too domain specific for Clippy to have reliable visibility into. Sure there are some cases where the author is just being lazy and could use a kick in the butt, but we're still left with an enormous number of suppressions where single chars are the most appropriate name. For example in the context of colors, a function using `h`, `s`, `l`, `r`, `g`, `b` is 100% sensible and spelling all those out is silly, but it's past the default lint threshold. --- changelog: Moved [`many_single_char_names`] to `pedantic`
I'm curious when you're doing this. Is there some kind of pattern that could be allowed here? I'm also curious if this is actually a common beginner mistake, or if that's just an baseless assertion in the docs.
This one seems to not work properly. enum Foo {
X,
Y([u8;255]),
Z([u8;200]),
}It's currently claiming
I've seen people do that for private helper functions. It's not unsound as a whole assuming they're careful, but the individual function definitely is. new_ret_no_self is probably due to false positives with generics. len_without_is_empty is probably also due to false positives. At least partially. new_without_default should probably only trigger on exported types. I've disabled this lint before on private types. clone_on_copy is almost definitely false positives which are fixed now. (suggestion didn't account for derive having the wrong trait bounds) It would probably be a good idea to filter on when the last update on the crate was. I imagine that would give a better idea into the current state of ignored lints. |
|
excessive_precision is too severe: decimals intended as f32s with less than 9 significant digits are linted against, e.g. let x: f32 = 1.111_111_1;This is 8 significant digits. It should permit at least 9, even if some are considered "excessive", because f32s can include up to 9 significant digits meaningfully, and there is various verbiage in the IEEE754 standard that provides guarantees around only float strings with at least 9 decimal digits. That little extra padding, means float parsing should always get the result and round it correctly. Likewise with f64, it should allow at least 17 before throwing a warning for the same reason. The reasoning around float_cmp may be overly strict... Correct handling of floats is hard to address via a simple lint. It seems particularly puzzling as a correctness lint, as most correctness lints are Almost Certainly Wrong, as opposed to merely Likely. And there are many cases, if one "knows what one is doing" that exact float comparison is quite appropriate. A warning would be fine but even that might be a bit much. Both of these are high on the frequent-allow list. |
|
Several instances of For a typical procedure call, the System V AMD64 ABI allows passing up to 14 arguments in registers if 8 of them belong to the {x,y,z}mm registers (e.g. floats). The AAPCS64 is slightly more lenient: 16 arguments, for similar reasons. Actually, slightly more for both, but it gets increasingly conditional. It is common to have to pass multiple floats as arguments to e.g. OpenGL APIs, which are beyond the control of the Rust programmer, but for which additional abstraction improves nothing (and the functions are likely perf-sensitive, so may be bad, as occasionally useless code is generated by building and dismantling a struct). While I do not believe clippy should become aware of ABI details, and it's not clippy's fault that compilers are suboptimal, it may be justified to skip floats, or to separately count them, or to just raise the argument threshold by several increments to account for this. |
|
I've updated the table at the top of this issue with links to browse the individual suppressions.
|
|
It looks like a lot of the |
|
I'd be curious to know how many of the |
|
It is possible that Clippy should omit a set of lints entirely inside |
|
Along with integration tests, that was my thinking. Cognitive complexity, too many lines, a number of performance lints, etc. |
|
For Someone will need to go through https://dtolnay.github.io/noisy-clippy/cast_possible_truncation.html and file obvious recognizable cases like #7486. pub fn f(val: u64) {
let digit = (val % 62) as u8;
println!("{}", digit);
}error: casting `u64` to `u8` may truncate the value
--> src/main.rs:2:17
|
2 | let digit = (val % 62) as u8;
| ^^^^^^^^^^^^^^^^ |
Demote float_cmp to pedantic See this issue: #7666 This is one of the most frequently suppressed lints. It is deny-by-default. It is not actually clearly wrong, as there are many instances where direct float comparison is actually desirable. It is only after operating on floats that they may lose precision, and that depends greatly on the operation. As most correctness lints have a much higher standard of error, being based on hard and fast binary logic, this should not be amongst them. A linter is not a substitute for observing the math carefully and running tests, and doing the desirable thing is even more likely to lead one to want exact comparisons. changelog: Demote [`float_cmp`] from correctness to pedantic lints
fix bug for large_enum_variants Fix the discussion problem in the issue of #7666 (comment) About the false positive problem of case: ```rust enum LargeEnum6 { A, B([u8;255]), C([u8;200]), } ```
fix bug for large_enum_variants Fix the discussion problem in the issue of #7666 (comment) About the false positive problem of case: ```rust enum LargeEnum6 { A, B([u8;255]), C([u8;200]), } ``` changelog: Fix largest_enum_variant wrongly identifying the second largest variant.
Random user here—this lint once singlehandedly sped up my application by This kind of improvement definitely mattered for this program, so I have |
|
@mikerite |
|
Throwing in another data point re: |
|
I also think that |
|
about I believe a better lint would be to check if the value is ignored and just after rematched. if let Ok(_) = foo {
let foo = foo.unwrap();
}Thus I think this lint would be very hard to implement and probably would not handle complex case. |
|
@Stargateur the The lint you are suggesting already exists with |
It's still mark as warning so this made CI fail https://github.com/rust-pcap/pcap/runs/6034264950?check_suite_focus=true#step:9:18 (thus I just saw pcap deny warning but I expect a lot of project do that) Anyway it's was my 2 cents about why this lint may be ignored sometime, fly away, thank for clippy ♥ |
|
What does it mean for one these blocks in the table to have a strike-through? Does it mean the community deemed it as "not noisy"? |
|
Those lints are disabled by default. So unless you opt-in to using those lints, you won't have to allow them. And if you opt-in globally to one of those lints and then allow them throughout the crate, we don't consider that as bad-practice, but rather encourage this. |
This is a similar methodology to #5418, but using all published crates on crates.io as the data source, rather than repos indexed by grep.app. The old table is a year and a half out of date at this point and hard to reproduce, so I've gone ahead and closed that issue. The code to generate the table below is in https://github.com/dtolnay/noisy-clippy.
The global column is counting #![allow(...)] attributes indicating that a lint has been suppressed at the whole crate or module level, and local is counting #[allow(...)] where a lint has been suppressed at only one place it is being triggered. The table is sorted by the sum.
85570cast_ptr_alignmentcorrectnesspedantic619285many_single_char_names707132cognitive_complexitycomplexitynursery334473unreadable_literalstylepedantic29774let_unit_valuestylepedantic620163cast_possible_truncation247384module_name_repetitions50694trivially_copy_pass_by_refperfpedantic381125needless_pass_by_valuestylepedantic45829unwrap_used358105cast_sign_loss39364unnecessary_wrapscomplexitypedantic33834missing_inline_in_public_items265106too_many_lines157142integer_arithmetic19494use_self16790cast_possible_wrap34211missing_errors_doc37203must_use_candidate18747missing_const_for_fn15371cast_precision_loss94125cast_lossless72117similar_names65121wildcard_imports15923unused_self29151doc_markdown11461match_same_arms11653missing_panics_doc11629redundant_pub_crate6969inline_always10533type_repetition_in_bounds4392non_ascii_literal7360option_if_let_elsepedanticnursery5762shadow_unrelated7940transmute_ptr_to_ptr5761missing_docs_in_private_items8434used_underscore_binding0111multiple_crate_versions1054expect_used5750indexing_slicing1577default_trait_access7910mut_mut6917exhaustive_structs5429as_conversions5726implicit_hasherstylepedantic1862print_stdout688pattern_type_mismatch5520wildcard_enum_match_arm5616range_plus_onecomplexitypedantic1458single_match_else2247match_boolstylepedantic4821struct_excessive_bools1949if_not_else5612option_optioncomplexitypedantic5810rc_bufferperfrestriction2146enum_glob_use643suspicious_operation_groupingsstylenursery062implicit_return610ref_option_ref518match_wild_err_armstylepedanticcorrectnessstylecorrectnessstyle4412semicolon_if_nothing_returned1336items_after_statements426let_underscore_must_use388exhaustive_enums396branches_sharing_code1827useless_transmute1924panic241unseparated_literal_suffix2715map_err_ignore1427float_arithmetic1526shadow_reuse138nonstandard_macro_bracesstylenursery1227string_lit_as_bytesstylenursery380zero_sized_map_values037dbg_macro1324unneeded_field_pattern1918useless_let_if_seqstylenursery269trivial_regexstylenursery1222integer_divisionpedanticrestriction921unnested_or_patternscomplexitypedantic326else_if_without_else326let_underscore_drop1413empty_enum1412fallible_impl_from1015match_wildcard_for_single_variants1114use_debug123redundant_else138suboptimal_flops147unimplemented120unreachable414expl_impl_clone_on_copy513verbose_bit_maskstylepedantic017clone_on_ref_ptr160needless_continue014cargo_common_metadata77future_not_send121mem_forget84await_holding_refcell_refcorrectnesspedantic111checked_conversions39from_iter_instead_of_collect66redundant_closure_for_method_calls47ptr_as_ptr73debug_assert_with_mut_call010multiple_inherent_impl64unsafe_derive_deserialize18explicit_iter_loop27panic_in_result_fn17decimal_literal_representation08match_on_vec_items08modulo_arithmetic53unused_async61await_holding_lockcorrectnesspedantic07default_numeric_fallback61explicit_deref_methods52unwrap_in_result42get_unwrap06map_unwrap_or23empty_line_after_outer_attr32exit50maybe_infinite_iter05wildcard_dependencies22inefficient_to_stringperfpedantic31naive_bytecount22range_minus_one30case_sensitive_file_extension_comparisons30disallowed_method12explicit_into_iter_loop03float_cmp_const03shadow_same02cloned_instead_of_copied11linkedlist02needless_for_each11same_functions_in_if_condition02string_add01copy_iterator01create_dir10filetype_is_file10fn_params_excessive_bools01if_then_some_else_none01inconsistent_struct_constructor01inline_asm_x86_intel_syntax01large_digit_groupsstylepedantic01map_flatten10print_stderr01todo10verbose_file_reads@rustbot label +A-category +C-tracking-issue +S-needs-discussion
The text was updated successfully, but these errors were encountered: