Restrict `use_self` on nested items
Fixes#3637Fixes#3463
These changes make it so that nested items aren't visited any more by the `use_self` lint.
I think visiting nested items should be possible (so that it uses a different `item_path` for the nested item), but I'm not sure whether it's viable and what the best approach would be.
- Can `item_path` be changed to a new `Self` path before visiting the item, and then changing it back afterwards?
- Alternatively, could a new visitor be created, re-using `check_trait_method_impl_decl`?
cast_ref_to_mut lint
I see this pattern way too often, and it's completely wrong. In fact, due to how common this incorrect pattern is, [the Rustonomicon specifically points this out](https://doc.rust-lang.org/nomicon/transmutes.html).
> - Transmuting an & to &mut is UB
> - Transmuting an & to &mut is always UB
> - No you can't do it
> - No you're not special
This is my first lint.
Trigger `use_self` lint in local macros
Closes#2098
The test currently only covers local macros. #2098 suggested this:
> You could add the macro in question into the `mini_macro` subcrate
But that doesn't work for a `macro_rules`:
```
error: cannot export macro_rules! macros from a `proc-macro` crate type currently
```
So I suggest leaving out the test for external macros, as using `in_external_macro` seems straigtforward enough. Alternatives would be to use to add an additional crate (overkill if you ask me), or test with a `proc-macro`.
Integrate rustfix into Clippy test suite
Once the [PR to compiletest-rs](https://github.com/laumann/compiletest-rs/pull/151) is reviewed and merged this fixes#2376.
I will create a separate tracking issue for adding `run-rustfix` to all tests.
Only trigger `infinite_iter` lint for infinitely allocating `collect()` calls
Fixes #3538
~Oh, I guess this should actually check other methods like `count` as well, not only `collect()`.~
Never mind, `collect` is the only of these functions that allocates a data structure.
Fix if_same_then_else false positive
This fixes false positive in #3559.
The problem was that `SpanlessEq` does not check patterns in declarations. So this two blocks considered equal.
```rust
if true {
let (x, y) = foo();
} else {
let (y, x) = foo();
}
```
Not sure if the proposed change is safe as `SpanlessEq` is used extensively in other lints, but I tried hard to come up with counterexample and failed.
Merge new_without_default_derive into new_without_default
Closes#3525, deprecating new_without_default_derive and moving both lints into new_without_default.
Fix false positives for `implicit_return` and `empty_loop` on macro expansion.
This PR only fixes `implicit_return` and `empty_loop`.
But I suspect this bug may affect a lot of other lints.
Teach `suspicious_else_formatting` about `if .. {..} {..}`
We essentially treat bare blocks `{..}` identically to `if .. {..}`, except for different lint messages.
Fixes#3044
Implements lint for order comparisons against bool (#3438)
As described on issue #3438, this change implements linting for `>` and `<` comparisons against both `boolean` literals and between expressions.
Adds lint for Vec<Box<T: Sized>>
This adds, and subsequently closes#3530. This is the first time I've ever worked with anything remotely close to internal Rust code, so I'm very much unsure about the if_chain! to figure this out!
I can't get rustfmt working on WSL with nightly 2018-12-07:
`error: component 'rustfmt' for target 'x86_64-unknown-linux-gnu' is unavailable for download`
Lint redundant clone of fields
Makes `redundant_clone` warn on unnecessary `foo.field.clone()` sometimes (it can detect an unnecessary clone only if the base of projection, `foo` in this case, is not used at all after that). This is enough for cases like `returns_tuple().0.clone()`.
If there are more than one such assignment, the last one may be
the one supplied to `clone` method.
Makes `find_stmt_assigns_to` internally reverses the iterator to make
the intent to "iterate statements backward" clear.
The path of `libc::c_void` has changes in 5c1a6b8a6d
The DefId path is now always platform specific like
`libc::windows::c_void`. This fixes our c_void detection to only check
the first and last elements.
This now only checks for wildcard_dependencies if the source is a
non-git source.
I tried adding a compiletest suite for the cargo lints, but I was unable
to override the `Cargo.toml` of the original executable.
I tested this manually by modifying the main `Cargo.toml`.
Fixes#3458
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
Some bugs and some documentation is unrelated to the Applicability change, but
these bugs were serious and the documentation was kind of required to
understand what's going on.
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]`.
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.
🏁
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.
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>
3368: added downsides to "known problems" for get_unwrap lint r=flip1995 a=humean
As a beginner I found this lint to be confusing because I was not sure how the `Option` type disappeared as conceptually I know that my `.get()` and Index could fail. Initially I thought maybe the compiler or clippy was smart enough to understand that it was impossible for my `.get()` to fail in this particular case, but it was explained to me that using the Index syntax is just shorthand for directly unwrapping the value:
https://doc.rust-lang.org/src/std/collections/hash/map.rs.html#1547
For beginners or users trying to iterate quickly it seems common to litter your code with `unwrap` or `except` as placeholders for where some explicit error handling might need to take place. I think it should be warned that using Index is merely more concise, but doesn't at all reduce the risk of panics and might in fact cause you to miss handling them in a future refactor.
Co-authored-by: Michael Rutter <michael.john.rutter@gmail.com>
Co-authored-by: Michael Rutter <humean@users.noreply.github.com>
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.
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>
3356: Fix warnings introduced by #3349 r=flip1995 a=flip1995
I missed these warnings during review, should have checked the Travis log first.
Co-authored-by: flip1995 <hello@philkrones.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>
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>
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>
3339: Check for known array length in `needless_range_loop` r=phansch a=HMPerson1
In `VarVisitor`, we now keep track of the type of the thing that was directly indexed and, if it's an array, check if the range's end is (or is past) the array's length.
Fixes #3033
Co-authored-by: HMPerson1 <hmperson1@gmail.com>
