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.
