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
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(_) ...`
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.
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
Single characters that are escaped weren't being searched / replaced
correctly in the hint string, so it was saying to replace, say,
`"\n"` with `"\n"` rather than `'\n'`.
The author lint was generating invalid code as shown on issue:
https://github.com/rust-lang-nursery/rust-clippy/issues/2442
I've changed the generated code to properly track cast
expressions.
Unfortunatelly, I've had to rewrite the `visit_decl` method, to
avoid that last if of the chain will be added. After looking at the code,
this last line was being added because of the `let x: char` part, but not
because of the `0x45df as char` expression.
It seems that let statements should not generate code on the author
lint, but I'm not sure that this is true or if I'm breaking
something on other code generation parts.
Finally, I've added a test for the author lint, but I'm not sure that
this needs to be added to the testsuite.
This makes it so that the `empty_line_after_outer_attribute` lint only
checks for newlines between the end of the attribute and the beginning
of the following item.
We need to check for the empty line count being bigger than 2 because
now the snippet of valid code contains only `\n` and splitting it
produces `["", ""]`
Invalid code will contain more than 2 empty strings.
Fix span so it no longer contains the whole train-wreck of code and only
points to the problem function (for the unwrap_or lint).
https://github.com/rust-lang-nursery/rust-clippy/issues/2422
Update ui test methods - it had several cases where the error message
span is now shorter
This fixes an incorrect suggestion from the `useless_attribute` lint
when using `cfg_attr`.
Additionally, it will not show a suggestion anymore, if the attribute
begins on a previous line, because it is much harder to construct the
span of multi-line `cfg_attr` attributes as they don't appear in the AST.
To fix it completely, one would have to parse upwards into the file,
and find the beginning of the `cfg_attr` attribute.
Doc comments are syntactic sugar for #[doc] attributes, so this lint was
catching them, too.
This commit makes it so that doc comments are ignored in this lint.
I think, for normal attributes it makes sense to warn about following empty
lines, for doc comments, less. This way the user has some freedom over
the formatting.
This adds a `suggest_remove_item` helper that will remove an item and
all trailing whitespace. This should handle both attributes on the same
line as the function and on a separate line; the function takes the
position of the original attribute.
As discussed in rust-lang/rust#47475 the #[inline] attribute is
currently allowed on trait methods without bodies (i.e. without a
default implementation). This is misleading as it could be interpreted
as affecting the implementations of the trait method. Add a lint for any
use of #[inline] on a trait method without a body.
Fixesrust-lang/rust#47475
