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.
This includes the type name, so is clear, and may be necessary.
There doesn't seem to be an obviously cleaner way to pull out the
literal text of the named type here.
Fixes#2879
This is a follow-up to #2951 that extends the logic to allow for
returning references inside structs/enums/unions. This was a simple
oversight in the first version and it's surprisingly easy to handle.
Currently this code will trigger `trivally_copy_pass_by_ref`:
```
struct OuterStruct {
field: [u8; 8],
}
fn return_inner(outer: &OuterStruct) -> &[u8] {
&outer.field
}
```
If we change the `outer` to be pass-by-value it will not live long
enough for us to return the reference. The above example is trivial but
I've hit this in real code that either returns a reference to either the
argument or in to `self`.
This suppresses the `trivally_copy_pass_by_ref` lint if we return a
reference and it has the same lifetime as the argument. This will likely
miss complex cases with multiple lifetimes bounded by each other but it
should cover the majority of cases with little effort.
The macro always negates the result of the given comparison in its
internal check which automatically triggered the lint. As its an
external macro there was no chance to do anything about it which lead
to a white listing of all external macros to prevent further issues.
This commit removes the logic in this PR that linted out-of-bounds constant `usize` indexing on arrays. That case is already handled by rustc's `const_err` lint. Beyond removing the linting logic, the test file and its associated stderr were updated to verify that const `usize` indexing operations on arrays are no longer handled by this `indexing_slicing` lint.
In this commit tests were added to ensure that tests with a `const` index behaved as expected.
In order to minimize the changes to the test's corresponding `stderr`, the tests were appended to
the end of the file.
This commit contains a few changes. In an attempt to clarify which test cases should and should not produce stderr it became clear that some cases were being handled incorrectly. In order to address these test cases, a minor re-factor was made to the linting logic itself.
The re-factor was driven by edge case handling including a need for additional match conditions for `ExprCall` (`&x[0..=4]`) and `ExprBinary` (`x[1 << 3]`). Rather than attempt to account for each potential `Expr*` the code was re-factored into simply "if ranged index" and an "otherwise" conditions.
The changes reflected in this commit (requested in PR #2790) are as follows:
- Extended `INDEXING_SLICING` documentation to include the array type so that it is clearer when indexing operations are allowed.
- Variable `ty` defined identically in multiple scopes was moved to an outer scope so it's only defined once.
- Added a missing return statement to ensure only one lint is triggered by a scenario.
- Prettified match statement with a `let` clause. (I learned something new!)
- Added `&x[5..].iter().map(|x| 2 * x).collect::<Vec<i32>>()` and `&x[2..].iter().map(|x| 2 * x).collect::<Vec<i32>>()` to the test cases. The first _should trigger the lint/stderr_ and the second _should not_.
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
allow condition to be a block: by calling visit_expr of the visitor directly on the condition instead of walk_expr on the whole expression, we bypass the match to ExprWhile that calls visit_expr on the condition and visit_block on the body. This allow to re-enable visit_block in the visitor, as it won't be called on the while body
allow condition to use static variables: maintain a list of static variables used, and if they are mutable
I have added test cases for comparisons with zero and one.
While implementing handling of one, incorrect handlings of zero
were also fixed.
fixes rust-lang-nursery/rust-clippy/#2554
This was caused by a macro in a different file.
The `target.span` was be in the file of the macro definition and the
`item.span` in the file of the calling code.
Given a map call like `x.field.map ...` the suggestion will contain:
`if let Some(x_field) ...`
Given a map call like `x.map ...` the suggestion will contain:
`if let Some(_x) ...`
Otherwise it will suggest: `if let Some(_) ...`
`reduce_nil_closure` mixed together a) 'is this a nil closure?' and b) 'can it
be reduced to a simple expression?'. Split the logic into two functions so we
can still generate a basic warning when the closure can't be simplified.
Clippy was issuing a warning when `format!` was used inside a macro.
That's a problem because macros have different syntax and can be outside
the control of the user.
This skips the `useless_format` check if the `format!` call is inside a
macro.
This commit makes `cargo clippy` output the build artifacts to a
separate directory if the `CLIPPY_DOGFOOD` env var is set. This should
prevent dogfood builds from interfering with regular builds.
This should help with issue #2595.
Before, when you had a block comment between an attribute and the
following item like this:
```rust
\#[crate_type = "lib"]
/*
*/
pub struct Rust;
```
It would cause a false positive on the lint, because there is an empty
line inside the block comment.
This makes sure that basic block comments are detected and removed from
the snippet that was created before.
Closes#2397.
This checks the def of the `ItemUse` path instead of checking the
capitalization of the path segements. It was noted that this def would
sometimes be `Def::Mod` instead of `Def::Enum` but it seems correct now.
`empty_line_after_outer_attribute` produced a false positive warning when
deriving `Copy` and/or `Clone` for an item.
It looks like the second point in [this comment][that_comment] is related,
as the attribute that causes the false positive has a path of
`rustc_copy_clone_marker`.
Fixes#2475
[that_comment]: https://github.com/rust-lang/rust/issues/35900#issuecomment-245978831
