Fix ICE in decimal_literal_representation lint
Handling the integer parsing properly instead of just unwrapping.
Note that the test is not catching the ICE because plain UI tests
[currently hide ICEs][compiletest_issue]. Once that issue is fixed, this
test would fail properly again.
Fixes#3891
[compiletest_issue]: https://github.com/laumann/compiletest-rs/issues/169
Handling the integer parsing properly instead of just unwrapping.
Note that the test is not catching the ICE because plain UI tests
[currently hide ICEs][compiletest_issue]. Once that issue is fixed, this
test would fail properly again.
[compiletest_issue]: https://github.com/laumann/compiletest-rs/issues/169
Fix `explicit_counter_loop` suggestion
#1670
This code seems to me to work, but I have two question.
* Because range expression desugared in hir, `Sugg::hir` doesn't add parenthesis to range expression. Which function is better to check range do you think, `check_for_loop_explicit_counter` or `hir_from_snippet`?
* Do you think we need to distinguish between range expression and struct expression that creates `std::ops::Range*`?
* Late Lint pass, catches:
* One liner: 0 -> null -> transmute
* One liner: std:null() -> transmute
* Const (which resolves to null) -> transmute
* UI Test case for Lint
* Updated test for issue 3849, because now the lint that code generated is in Clippy.
* Expanded `const.rs` miri-based Constant Folding code, to cover
raw pointers
The moved tests were part of `tests/ui/literals.rs` before. Now they are
placed in `tests/ui/unreadable_literal.rs`, which now also runs
`rustfix` on these 4 extra let statements.
Add `doc(include = ...)` detection to `missing_docs_in_private_items`
The whole `missing documentation in crate` part doesn't have any tests. If I should add test cases tell me.
Run rustfix for string_lit_as_bytes tests
This moves the `string_lit_as_bytes` tests into a new file and enables
rustfix tests for them.
cc #3603, #2038
Fix `boxed_local` suggestion
Don't warn about an argument that is moved into a closure.
ExprUseVisitor doesn't walk into nested bodies so use a new
visitor that collects the variables that are moved into closures.
Fixes#3739
* Ran automatic naming update
* Formalized rename of `cyclomatic_complexity` to `cognitive_complexity`
** Added the rename to `lib.rs`
** Added rename test
* Added warning for deprecated key `cyclomatic_complexity_threshold` and tests for it
* Added deprecation status for Clippy's builtin attribute
* Updated tests for new builtin attribute renaming
Fix `bool_comparison` with non-`bool` expressions
Fixes#3703.
It just moves around the type check that was already there for some comparison to all of them, because if one type isn't `bool`, none of those comparison can be simplified.
Fix ICE #3719+#3718 in lint match_ref_pats
Fixes#3719
This conveniently also fixes#3718
The ICE occurs when the match expression was a macro call, where the macro was defined in another file. Since we don't have the ability to reproduce this behavior with our UI tests (AFAIK), I couldn't add a test reproducing this ICE.. However, I added a test which is related to the ICE, to show the new behavior of the lint.
I tested it with the mscheme repo locally and the ICE didn't happen anymore.
r? @matthiaskrgr
Fix ICE #3747
I'm not sure if this was the correct approach.
I don't know if I put tests/ui/crashses/ice-3747.rs in correct place because the test always passed when I ran it with `cargo test`, even without the fix applied.
If I run that test with `env CLIPPY_TESTS=true cargo run --bin clippy-driver -- -L ./target/debug tests/ui/crashes/ice-3747.rs` then the test correctly fails without the fix applied
fixes#3747
Many people run rustfmt automatically on save. Format-dependent tests
should be marked with `#[rustfmt::skip]` to prevent accidental
reformatting from this. As a bonus the rest of the code can the formatted.
Make needless_range_loop not applicable to structures without iter method
Fixes https://github.com/rust-lang/rust-clippy/issues/3788
Now we will start lint indexed structure only if it has known iter or iter_mut method implemented.
Don't warn about an argument that is moved into a closure.
ExprUseVisitor doesn't walk into nested bodies so use a new
visitor that collects the variables that are moved into closures.
Fixes#3739
Don't check [print/write]_with_newline on raw strings
Some tests for #3778 and some maybe-not-the-greatest code that passes those tests!
I didn't run `fmt` because a) it doesn't seem to install on nightly for me, and b) on stable it wanted to apply formatting to over 90 files. Happy to make any tweaks though!
I suspect this contribution may require more than just tweaks. I'm still sort of new to rust so it may not be idiomatic, and the specific approach I took feels a little heavy-handed and brittle. I'm happy to make changes with some guidance, or equally happy if this gives a starting place for someone else to do it better :)
This test doesn't reproduce the ICE since it only happens, when the macro is defined in another file.
Currently we can't add tests with multiple files AFAIK
Also using the auxiliary folder didn't help
Add a lint to warn on `T: Drop` bounds
**What it does:** Checks for generics with `std::ops::Drop` as bounds.
**Why is this bad?** `Drop` bounds do not really accomplish anything.
A type may have compiler-generated drop glue without implementing the
`Drop` trait itself. The `Drop` trait also only has one method,
`Drop::drop`, and that function is by fiat not callable in user code.
So there is really no use case for using `Drop` in trait bounds.
**Known problems:** None.
**Example:**
```rust
fn foo<T: Drop>() {}
```
Fixes#3773
Both regular strings and raw strings can contain literal newlines. This commit
extends the lint to also warn about terminating strings with these.
Behaviour handling for raw strings is also moved into `check_newlines` by
passing in the `is_raw` boolean from `check_tts` as
[suggested](https://github.com/rust-lang/rust-clippy/pull/3781#pullrequestreview-204663732)
Literal `\n` characters (not a newline) in a `r"raw"` string should not
fail the lint.
This affects both write_with_newline and print_with_newline, so it is added in
both places.
I also copied a missing test case from write_with_newline over to
print_with_newline and added a note that one of those tests is supposed to
fail.
**What it does:** Checks for generics with `std::ops::Drop` as bounds.
**Why is this bad?** `Drop` bounds do not really accomplish anything.
A type may have compiler-generated drop glue without implementing the
`Drop` trait itself. The `Drop` trait also only has one method,
`Drop::drop`, and that function is by fiat not callable in user code.
So there is really no use case for using `Drop` in trait bounds.
**Known problems:** None.
**Example:**
```rust
fn foo<T: Drop>() {}
```
Fix ICE in needless_pass_by_value lint
If I understand it correctly, we were first creating a type with a
`RegionKind::ReErased` region and then deleted it again in
`util::implements_trait` with:
cx.tcx.erase_regions(&ty);
causing the type query to fail.
It looks like using `ReEmpty` works around that deletion.
Fixes#3144
Macro check for assertion_on_constants lint
The `assertion_on_constants` lint currently has following output for this code [Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6f2c9df6fc50baf847212d3b5136ee97):
```rust
macro_rules! assert_const {
($len:expr) => {
assert!($len > 0);
}
}
fn main() {
assert_const!(3);
assert_const!(-1);
}
```
```
warning: assert!(const: true) will be optimized out by the compiler
--> src/main.rs:3:9
|
3 | assert!($len > 0);
| ^^^^^^^^^^^^^^^^^^
...
8 | assert_const!(3);
| ---------------- in this macro invocation
|
= note: #[warn(clippy::assertions_on_constants)] on by default
= help: remove it
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#assertions_on_constants
warning: assert!(const: false) should probably be replaced
--> src/main.rs:3:9
|
3 | assert!($len > 0);
| ^^^^^^^^^^^^^^^^^^
...
9 | assert_const!(-1);
| ----------------- in this macro invocation
|
= help: use panic!() or unreachable!()
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#assertions_on_constants
```
This is contradictory. This lint should not trigger if the `assert!` is in a macro itself.
If I understand it correctly, we were first creating a type with a
`RegionKind::ReErased` region and then deleted it again in
`util::implements_trait` with:
cx.tcx.erase_regions(&ty);
causing the type query to fail.
It looks like using `ReEmpty` works around that deletion.
Fix `cast_sign_loss` false positive
This checks if the value is a non-negative constant before linting about
losing the sign.
Because the `constant` function doesn't handle const functions, we check if
the value is from a call to a `max_value` function directly. A utility method
called `get_def_path` was added to make checking for the function paths
easier.
Fixes#2728
Adding lint test for excessive LOC.
This is a WIP for #2377. Just wanted to pull in because I had a few questions:
1. Is it okay that I'm approaching this via counting by looking at each line in the snippet instead of looking at the AST tree? If there's another way to do it, I want to make sure I'm doing the correct way, but I wasn't sure since the output AST JSON doesn't seem to contain whitespace.
2. My function is definitely going to trigger the lint, so also wanted to see if there was something obvious I could do to reduce it.
3. Are the two tests fine, or is there something obvious I'm missing?
4. Obviously bigger question - am I approaching the line count correctly. Current strategy is count a line if it contains some code, so skip if it's just comments or empty.
`hir::Ty` doesn't seem to know anything about type bounds and
`cx.tcx.type_of(def_id)` caused an ICE when it was passed a generic type
with a bound:
```
src/librustc_typeck/collect.rs:1311: unexpected non-type Node::GenericParam: Type { default: None, synthetic: None }
```
Converting it to a proper `Ty` fixes the ICE and catches a few more
places where the lint applies.
This checks if the value is a non-negative constant before linting about
losing the sign.
Because the `constant` function doesn't handle const functions, we check if
the value is from a call to a `max_value` function directly. A utility method
called `get_def_path` was added to make checking for the function paths
easier.
Fixes#2728
Add initial version of const_fn lint
This adds an initial version of a lint that can tell if a function could be `const`.
TODO:
- [x] Finish up the docs
- [x] Fix the ICE
cc #2440
Prevent incorrect cast_lossless suggestion in const_fn
`::from` is not a const fn, so applying the suggestion of
`cast_lossless` would fail to compile. The fix is to skip the lint if
the cast is found inside a const fn.
Fixes#3656
`::from` is not a const fn, so applying the suggestion of
`cast_lossless` would fail to compile. The fix is to skip the lint if
the cast is found inside a const fn.
* master: (58 commits)
Rustfmt all the things
Don't make decisions on values that don't represent the decision
Improving comments.
Rustup
Added rustfix to the test.
Improve span shortening.
Added "make_return" and "blockify" convenience methods in Sugg and used them in "needless_bool".
Actually check for constants.
Fixed potential mistakes with nesting. Added tests.
formatting fix
Update clippy_lints/src/needless_bool.rs
formatting fix
Fixing typo in CONTRIBUTING.md
Fix breakage due to rust-lang/rust#57651
needless bool lint suggestion is wrapped in brackets if it is an "else" clause of an "if-else" statement
Fix automatic suggestion on `use_self`.
Remove negative integer literal checks.
Fix `implicit_return` false positives.
Run rustfmt
Fixed breakage due to rust-lang/rust#57489
...
Fix automatic suggestion on `use_self`.
In an example like this:
```rust
impl Example {
fn fun_1() { }
fn fun_2() {
Example::fun_1();
}
}
```
Clippy tries to replace `Example::fun_1` with `Self`, loosing `::fun_1` in the process, it should rather try to replace `Example` with `Self`.
**Question**
- There may be other paths that need the same treatment, but I'm not sure I understand them fully:
- e648adf086/clippy_lints/src/use_self.rs (L94-L96)
- e648adf086/clippy_lints/src/use_self.rs (L225-L229)
Fix `implicit_return` false positives.
Fixes the following false positives:
- linting on `if let` without `else` in a `loop` even with a present `return`
- linting on `unreachable!()`
Catch up with `format_args` change
Catches up with a change in rust-lang/rust#57537. (Since the optimization is optional, this clippy PR can be merged before the rustc PR.)
Happened to fix a bug in `expect_fun_call`, that is the lint ignores more than
one arguments to `format`.
```
warning: use of `expect` followed by a function call
--> src/main.rs:2:17
|
2 | Some("foo").expect(format!("{} {}", 1, 2).as_ref());
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try this: `unwrap_or_else(|| panic!("{} {}", 1))`
|
```
Catches up with a change in rust-lang/rust#57537
Happened to fix a bug in `expect_fun_call`, that is the lint ignores more than
one arguments to `format`.
`cloned` requires that the elements of the iterator must be references. This
change determines if that is the case by examining the type of the closure
argument and suggesting `.cloned` only if it is a reference. When the closure
argument is not a reference, it suggests removing the `map` call instead.
A minor problem with this change is that the new check sometimes overlaps
with the `clone_on_copy` lint.
Fixes#498
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`?
Revert the random_state lint.
Remove the random_state lint until it or rustc has been fixed to no longer crash with debug assertions (see #3628)
We can't update clippy in the rustc repo because of this which is blocking nightlies because toolstate is already broken.
fixes#3628
Add run-rustfix where it already works
This PR adds `// run-rustfix` headers to tests for `MachineApplicable` lints where
applying the suggestions works without any errors.
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`.
UI test cleanup: Extract lint from methods.rs test
Extracts the `result_map_unwrap_or_else` lint into a separate test file.
This also extracts the `IteratorFalsePositives` struct and impl into
`auxiliary/option_helpers.rs`.
cc #2038
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.
Teach `suspicious_else_formatting` about `if .. {..} {..}`
We essentially treat bare blocks `{..}` identically to `if .. {..}`, except for different lint messages.
Fixes#3044
There is no map_unit_fn.rs whose output would be diffed with map_unit_fn.stderr
map_unit_fn.stderr was renamed 8 months ago from option_map_unit_fn.stderr
but option_map_unit_fn.{stderr,rs} both remain and are in use.
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()`.
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]`.
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.
3397: UI test cleanup: Extract expect_fun_call tests r=matthiaskrgr a=phansch
Note that the new stderr file does not include a `shadow-unrelated`
error, because the new UI test file does not use `#![warn(clippy::all)]`
cc #2038
3398: UI test cleanup: Extract match_overlapping_arm tests r=matthiaskrgr a=phansch
cc #2038
Co-authored-by: Philipp Hansch <dev@phansch.net>
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>
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>
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>
Boxes are a bit magic in that they need to use `*` to get an owned value
out of the box. They implement `Deref` but that only returns a
reference. This means an easy way to convert an `Option<Box<T>>` to an
`<Option<T>` is:
```
box_option.map(|b| *b)
```
However, since b36bb0a6 the `map_clone` lint is detecting this as an
attempt to copy the box. Fix by excluding boxes completely from the
deref part of this lint.
Fixes#3274
This collapses both lint tests into one file.
Somehow allowing the other lint in the respective files did not work
correctly. Maybe that's fixed as part of fixing #3198.
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
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
