Instead of searching for all the successive expressions after a vector
allocation, check only the first expression.
This is done to minimize the amount of false positives of the lint.
Add lint to detect slow zero-filled vector initialization. It detects
when a vector is zero-filled with extended with `repeat(0).take(len)`
or `resize(len, 0)`.
This zero-fillings are usually slower than simply using `vec![0; len]`.
3353: float support added for mistyped_literal_suffixes lint r=mikerite a=Maxgy
I implemented the mistyped_literal_suffixes lint for float literals.
```
#![allow(unused_variables)]
fn main() {
let x = 1E2_32;
let x = 75.22_64;
}
```
Given the above, the additional check suggests the variables to be written as `let x = 1E2_f32` and `let x = 75.22_f64`.
Fixes#3167
Co-authored-by: Maxwell Anderson <maxwell.brayden.anderson@gmail.com>
`possible_missing_comma` should only trigger when the binary operator has
unary equivalent. Otherwise, it's not possible to insert a comma without
breaking compilation. The operators identified were `+`, `&`, `*` and `-`.
This fixes the specific examples given in issues #3244 and #3396
but doesn't address the conflict this lint has with the style of starting
a line with a binary operator.
3397: UI test cleanup: Extract expect_fun_call tests r=matthiaskrgr a=phansch
Note that the new stderr file does not include a `shadow-unrelated`
error, because the new UI test file does not use `#![warn(clippy::all)]`
cc #2038
3398: UI test cleanup: Extract match_overlapping_arm tests r=matthiaskrgr a=phansch
cc #2038
Co-authored-by: Philipp Hansch <dev@phansch.net>
3217: Fix string_lit_as_bytes lint for macros r=phansch a=yaahallo
Prior to this change, string_lit_as_bytes would trigger for constructs
like `include_str!("filename").as_bytes()` and would recommend fixing it
by rewriting as `binclude_str!("filename")`.
This change updates the lint to act as an EarlyLintPass lint. It then
differentiates between string literals and macros that have bytes
yielding alternatives.
Closes#3205
3366: Don't expand macros in some suggestions r=oli-obk a=phansch
Fixes#1148Fixes#1628Fixes#2455Fixes#3023Fixes#3333Fixes#3360
Co-authored-by: Jane Lusby <jlusby42@gmail.com>
Co-authored-by: Philipp Hansch <dev@phansch.net>
Prior to this change, string_lit_as_bytes would trigger for constructs
like `include_str!("filename").as_bytes()` and would recommend fixing it
by rewriting as `binclude_str!("filename")`.
This change updates the lint to act as an EarlyLintPass lint. It then
differentiates between string literals and macros that have bytes
yielding alternatives.
Closes#3205
3355: Lint to remove redundant `clone()`s r=oli-obk a=sinkuu
This PR adds lint `redundant_clone`. It suggests to remove redundant `clone()` that clones a owned value that will be dropped without any usage after that.
Real-world example: https://github.com/rust-lang/rust/compare/7b0735a..sinkuu:redundant_clone2
Co-authored-by: Shotaro Yamada <sinkuu@sinkuu.xyz>
3331: Disable arithmetic lints in constant items r=oli-obk a=pengowen123
Currently this will not catch cases in associated constants. I'm not sure whether checking spans is the best way to solve this issue, but I don't think it will cause any problems.
Fixes#1858
Co-authored-by: Owen Sanchez <pengowen816@gmail.com>
3338: new_ret_no_self false positives r=flip1995 a=JoshMcguigan
~~WORK IN PROGRESS~~
I plan to fix all of the false positives in #3313 in this PR, but I wanted to open it now to start gathering feedback.
In this first commit, I've updated the lint to allow tuple return types as long as `Self` shows up at least once, in any position of the tuple. I believe this is the broadest possible interpretation of what should be allowed for tuple return types, but I would certainly be okay making the lint more strict.
fixes#3313
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
3350: Don't emit `new_without_default_derive` if an impl of Default exists regardless of generics r=oli-obk a=pengowen123
Fixes#2226
Co-authored-by: Owen Sanchez <pengowen816@gmail.com>
