I believe if the user already decided to put underscores in their
literal, Clippy should be willing to believe that they put a number of
underscores that they felt was readable.
This lint looks for:
let mut vec = Vec::with_capacity(len);
vec.set_len(len);
The suggested replacement is `vec![0; len]`.
This is far too opinionated to be a deny-by-default lint because the performance
characteristics of the suggested replacement are totally different.
I am not convinced that this lint has value beyond what deny(unsafe_code) gives
you. Unsafe code is unsafe but please don't deny-by-default lint it if that's
the only reason.
Warning was:
warning: the feature `macro_at_most_once_rep` has been stable since 1.32.0 and no longer requires an attribute to enable
--> clippy_lints/src/lib.rs:19:12
|
19 | #![feature(macro_at_most_once_rep)]
| ^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(stable_features)] on by default
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]`.
I noticed that I suppress this lint in many of my projects.
https://github.com/search?q=needless_pass_by_value+user%3Adtolnay&type=Codehttps://github.com/search?q=needless_pass_by_value+user%3Aserde-rs&type=Code
Upon further inspection, this lint has a *long* history of false
positives (and several remaining).
Generally I feel that this lint is the definition of pedantic and should
not be linted by default.
#[derive(Debug)]
enum How {
ThisWay,
ThatWay,
}
// Are we really better off forcing the call sites to write f(&_)...?
fn f(how: How) {
println!("You want to do it {:?}", how);
}
fn main() {
f(How::ThatWay);
}
This finishes up the rewrite of `update_lints.py` in Rust. More
specifically, this
* adds the `--check` flag and handling to clippy_dev
* tracks file changes over the different calls to `replace_region_in_file`
* only writes changes to files if the `--check` flag is *not* used
* runs `./util/dev update_lints --check` on CI instead of the old script
* replaces usage of the `update_lints.py` script with an error
`./util/dev update_lints` behaves 99% the same as the python script.
The only difference that I'm aware of is an ordering change to
`clippy_lints/src/lib.rs` because underscores seem to be sorted
differently in Rust and in Python.
🏁
3388: RIIR update lints: Generate deprecated lints r=phansch a=phansch
The update script now also generates the 'register_removed' section in
`clippy_lints/src/lib.rs`.
Also, instead of using `let mut store ...`, I added a new identifier
line so that the replacement will continue to work in case `let mut
store ...` ever changes.
cc #2882
Co-authored-by: Philipp Hansch <dev@phansch.net>
The update script now also generates the 'register_removed' section in
`clippy_lints/src/lib.rs`.
Also, instead of using `let mut store ...`, I added a new identifier
line so that the replacement will continue to work in case `let mut
store ...` ever changes.
3349: Fixes#3347: Lint for wildcard dependencies in Cargo.toml r=ordovicia a=ordovicia
Add a lint for wildcard dependencies in Cargo.toml.
How should I write a test for this lint?
Fixes#3347
Co-authored-by: Hidehito Yabuuchi <hdht.ybuc@gmail.com>
Handles cases of `.collect().len()`, `.collect().is_empty()`, and
`.collect().contains()`. This lint is intended to be generic enough to
be added to at a later time with other similar patterns that could be
optimized.
Closes#3034
Make explicit_iter_loop and explicit_into_iter_loop allow-by-default, so
that people can turn them on if they want to enforce that style; avoid
presenting them as *the* idiomatic Rust style, rather than just *a* style.
Recategorize `range_plus_one` and `range_minus_one` to `complexity`.
This moves `range_plus_one` out of the nursery as the inclusive range
syntax is now stable. Both are moved to `complexity` as it is more
consistent with other lints such as `int_plus_one`.
Warning was:
warning: the feature `macro_vis_matcher` has been stable since 1.29.0 and no longer requires an attribute to enable
--> src/lib.rs:4:12
|
4 | #![feature(macro_vis_matcher)]
| ^^^^^^^^^^^^^^^^^
|
= note: #[warn(stable_features)] on by default
The changes reflected in this commit are as follows:
- Revised `IndexingSlicingPass` struct name to IndexingSlicing for consistency with the rest of the code base.
- Revised match arm condition to use `(..)` shorthand in favor of `(_, _, _)`.
- Restored a couple telling variable names.
- Calls to `cx.span_lint` were revised to use `utils::span_help_and_lint`.
- Took a stab at refactoring some generalizable calls to `utils::span_help_and_lint` to minimize duplicate code.
- Revised INDEXING_SLICING declaration to pedantic rather than restriction.
- Added `&x[0..].get(..3)` to the test cases.
This commit renames instances of `array_indexing` to `indexing_slicing` and moves the `indexing_slicing` lint to the `clippy_pedantic` group. The justification for this commit's changes are detailed in the previous commit's message.
Hey there clippy team! I've made some assumptions in this PR and I'm not at all certain they'll look like the right approach to you. I'm looking forward to any feedback or revision requests you have, thanks!
Prior to this commit the `indexing_slicing` lint was limited to indexing/slicing operations on arrays. This meant that the scope of a really useful lint didn't include vectors. In order to include vectors in the `indexing_slicing` lint a few steps were taken.
The `array_indexing.rs` source file in `clippy_lints` was renamed to `indexing_slicing.rs` to more accurately reflect the lint's new scope. The `OUT_OF_BOUNDS_INDEXING` lint persists through these changes so if we can know that a constant index or slice on an array is in bounds no lint is triggered.
The `array_indexing` tests in the `tests/ui` directory were also extended and moved to `indexing_slicing.rs` and `indexing_slicing.stderr`.
The `indexing_slicing` lint was moved to the `clippy_pedantic` lint group.
A specific "Consider using" string was added to each of the `indexing_slicing` lint reports.
At least one of the test scenarios might look peculiar and I'll leave it up to y'all to decide if it's palatable. It's the result of indexing the array `x` after `let x = [1, 2, 3, 4];`
```
error: slicing may panic. Consider using `.get(..n)`or `.get_mut(..n)`instead
--> $DIR/indexing_slicing.rs:23:6
|
23 | &x[0..][..3];
| ^^^^^^^^^^^
```
The error string reports only on the second half's range-to, because the range-from is in bounds!
Again, thanks for taking a look.
Closes#2536
This checks for things like
if x.is_some() {
x.unwrap()
}
which should be written using `if let` or `match` instead.
In the process I moved some logic to determine which variables are
mutated in an expression to utils/usage.rs.
- added tests for common usages of format and as_str arguments to expect
- added tests for usages of Option and Result types
- given performance impact of passing non literal expressions to expect, added to perf group
