Commit graph

717 commits

Author SHA1 Message Date
bors
cfd720d506 Auto merge of #5563 - ThibsG:MergeLints, r=flip1995
Merge some lints together

This PR merges following lints:

- `block_in_if_condition_expr` and `block_in_if_condition_stmt` → `blocks_in_if_conditions`
- `option_map_unwrap_or`, `option_map_unwrap_or_else` and `result_map_unwrap_or_else` → `map_unwrap`
- `option_unwrap_used` and `result_unwrap_used` → `unwrap_used`
- `option_expect_used` and `result_expect_used` → `expect_used`
- `wrong_pub_self_convention` into `wrong_self_convention`
- `for_loop_over_option` and `for_loop_over_result` → `for_loops_over_fallibles`

Lints that have already been merged since the issue was created:
- [x] `new_without_default` and `new_without_default_derive` → `new_without_default`

Need more discussion:
- `string_add` and `string_add_assign`: do we agree to merge them or not? Is there something more to do? → **not merge finally**
- `identity_op` and `modulo_one` → `useless_arithmetic`: seems outdated, since `modulo_arithmetic` has been created.

fixes #1078

changelog: Merging some lints together:
- `block_in_if_condition_expr` and `block_in_if_condition_stmt` → `blocks_in_if_conditions`
- `option_map_unwrap_or`, `option_map_unwrap_or_else` and `result_map_unwrap_or_else` → `map_unwrap_or`
- `option_unwrap_used` and `result_unwrap_used` → `unwrap_used`
- `option_expect_used` and `result_expect_used` → `expect_used`
- `for_loop_over_option` and `for_loop_over_result` → `for_loops_over_fallibles`
2020-05-16 20:17:11 +00:00
ThibsG
ab87f87ba0 Fix CHANGELOG.md and lint names plural 2020-05-15 18:27:11 +02:00
ThibsG
93386563f6 Rename lint map_unwrap to map_unwrap_or and register lints as renamed 2020-05-15 09:17:39 +02:00
David Tolnay
95399f8f94
Downgrade useless_let_if_seq to nursery 2020-05-14 09:57:36 -07:00
ThibsG
adbdf7549c Merge for_loop_over_option and for_loop_over_result lints into for_loop_over_fallible lint 2020-05-14 16:01:07 +02:00
ThibsG
0e8be599cd Merge option_expect_used and result_expect_used lints into expect_used lint 2020-05-14 16:01:07 +02:00
ThibsG
bcf61666bd Merge option_unwrap_used and result_unwrap_used lints into unwrap_used lint 2020-05-14 16:01:07 +02:00
ThibsG
6cbdd1e49d Merge option_map_unwrap_or, option_map_unwrap_or_else and result_map_unwrap_or_else lints into map_unwrap lint 2020-05-14 15:56:17 +02:00
ThibsG
945c944709 Merge block_in_if_condition_expr and block_in_if_condition_stmt lints into block_in_if_condition lint 2020-05-14 15:56:17 +02:00
Eduardo Broto
0f2b1193f9 Remove reverse_range_loop lint 2020-05-13 20:33:32 +02:00
Eduardo Broto
8ffa0bfaa2 New lint: reversed_empty_ranges 2020-05-13 20:33:32 +02:00
Camille GILLOT
8ab3224b3b
Fix clippy. 2020-05-11 21:26:39 +02:00
Glenn Hope
ad92486d52 Add check for "test" in parent name. Include flag for disabling wildcard import exceptions 2020-05-09 11:09:38 -07:00
Eduardo Broto
3b58d66b22 Add the manual_async_fn lint 2020-05-07 21:42:40 +02:00
bors
cc9088f287 Auto merge of #5550 - ebroto:manual_non_exhaustive, r=flip1995
Implement the manual_non_exhaustive lint

Some implementation notes:
* Not providing automatic fixups because additional changes may be needed in other parts of the code, e.g. when constructing a struct.
* Even though the attribute is valid on enum variants, it's not possible to use the manual implementation of the pattern because the visibility is always public, so the lint ignores enum variants.
* Unit structs are also ignored, it's not possible to implement the pattern manually without fields.
* The attribute is not accepted in unions, so those are ignored too.
* Even though the original issue did not mention it, tuple structs are also linted because it's possible to apply the pattern manually.

changelog: Added the manual non-exhaustive implementation lint

Closes #2017
2020-05-02 13:53:39 +00:00
flip1995
10e3f9bdb8
Move match_on_vec_items to pedantic 2020-05-01 23:02:31 +02:00
Eduardo Broto
f072ded3bf Implement the manual_non_exhaustive lint 2020-05-01 02:10:16 +02:00
bors
d13ffbe3fe Auto merge of #5522 - CrazyRoka:match_vec_item, r=phansch
New  lint `match_vec_item`

Added new lint to warn a match on index item which can panic. It's always better to use `get(..)` instead.
Closes #5500
changelog: New lint `match_on_vec_items`
2020-04-27 06:02:05 +00:00
Eduardo Broto
149f6d6046 Implement mismatched_target_os lint 2020-04-26 21:27:29 +02:00
CrazyRoka
b574941dcb Updated lint info in lib.rs 2020-04-26 18:11:21 +03:00
Philipp Krones
a33d64a4c3
Rollup merge of #5505 - flip1995:avoid_running_lints, r=matthiaskrgr
Avoid running cargo+internal lints when not enabled

r? @matthiaskrgr

changelog: none
2020-04-25 21:06:27 +02:00
CrazyRoka
63b451ea25 Renamed lint to match_on_vec_items 2020-04-25 11:34:16 +03:00
CrazyRoka
96e2bc80f5 Added lint match_vec_item 2020-04-24 22:45:15 +03:00
David Tolnay
ef28361293
Downgrade match_bool to pedantic 2020-04-23 16:30:06 -07:00
flip1995
14f596cb74
Only run cargo lints, when they are warn/deny/forbid 2020-04-22 20:32:37 +02:00
Andy Weiss
6c25c3c381 Lint for holding locks across await points
Fixes #4226

This introduces the lint await_holding_lock. For async functions, we iterate
over all types in generator_interior_types and look for types named MutexGuard,
RwLockReadGuard, or RwLockWriteGuard. If we find one then we emit a lint.
2020-04-21 21:07:43 -07:00
bors
6ce05bf849 Auto merge of #5332 - DevinR528:if-let-else-mutex, r=flip1995
If let else mutex

changelog: Adds lint to catch incorrect use of `Mutex::lock` in `if let` expressions with lock calls in any of the blocks.

closes: #5219
2020-04-20 20:21:33 +00:00
Eduardo Broto
b7f85e8706 Apply suggestions from PR review
* Move the lint to pedantic
* Import used types instead of prefixing with `hir::`
2020-04-20 20:05:15 +02:00
Devin R
001a42e632 progress work on suggestion for auto fix 2020-04-20 06:29:59 -04:00
Eduardo Broto
00b4f2819f Implement unsafe_derive_deserialize lint 2020-04-19 23:26:17 +02:00
xiongmao86
bdd32e7700 Implement collapsible_span_lint_calls lint. 2020-04-18 18:13:50 +08:00
pmk21
7c52e51d79 Added basic lint and tests 2020-04-18 11:39:54 +05:30
Roland Kuhn
d2cbbff217 add lint futures_not_send 2020-04-17 13:54:05 +02:00
Philipp Krones
ceea3c6a35
Rollup merge of #5248 - ThibsG:ConstValues, r=flip1995
Add lint on large non scalar const

This PR adds the new lint `non_scalar_const` that aims to warn against `const` declaration of large arrays. For performance, because of inlining, large arrays should be preferably declared as `static`.

Note: i made this one to warn on all const arrays, whether they are in a body function or not. I don't know if this is really necessary, i could just reduce this lint to variables out of function scope.

Fixes: #400

changelog: add new lint for large non-scalar types declared as const
2020-04-15 20:12:28 +02:00
ThibsG
3c2bbcf00e Better precedence case management + more tests 2020-04-15 17:18:12 +02:00
ThibsG
72b9ae2a10 Use only check_expr with parent expr and precedence 2020-04-15 17:18:12 +02:00
ThibsG
6b4ab82746 Global rework + fix imports 2020-04-15 17:18:12 +02:00
Tom Milligan
b2d986850d Working basic dereference clip 2020-04-15 17:18:12 +02:00
Philipp Krones
90fb50fabf
Revert "Downgrade new_ret_no_self to pedantic" 2020-04-09 19:38:20 +02:00
ThibsG
629cc4ada3 Update doc generation script 2020-04-09 09:17:41 +02:00
ThibsG
380f7218b3 Add lint on large const arrays 2020-04-09 09:09:39 +02:00
bors
c25f26d4ca Auto merge of #5411 - dtolnay:hasher, r=flip1995
Downgrade implicit_hasher to pedantic

From the [documentation](https://rust-lang.github.io/rust-clippy/master/index.html#implicit_hasher), this lint is intended to suggest:

```diff
- pub fn foo(map: &mut HashMap<i32, i32>) { }

+ pub fn foo<S: BuildHasher>(map: &mut HashMap<i32, i32, S>) { }
```

I think this is pedantic. I get that this lint can benefit core libraries like serde, but that's exactly the use case for pedantic lints; a library like serde will [enable clippy_pedantic](fd6741f4b0/src/lib.rs (L304)) and take the time to go through everything possible. Similar for libraries doing a libz blitz style checkup before committing to a 1.0 release; it would make sense to run through all the available pedantic lints then.

But otherwise, for most codebases and certainly for industrial codebases, the above suggested change just makes the codebase more obtuse for questionable benefit.

changelog: Remove implicit_hasher from default set of enabled lints
2020-04-08 17:14:09 +00:00
David Tolnay
5f92faec6d
Downgrade implicit_hasher to pedantic 2020-04-08 08:43:20 -07:00
David Tolnay
899a1b5598
Move cognitive_complexity to nursery 2020-04-08 08:37:20 -07:00
Philipp Krones
7cb5180dfb
Rollup merge of #5420 - dtolnay:newret, r=flip1995
Downgrade new_ret_no_self to pedantic

As motivated by #5418. This is the second most widely suppressed Clippy style lint, and [this grep.app search](https://grep.app/search?q=%5C%5Ballow%5C%28.%2Aclippy%3A%3Anew_ret_no_self%5Cb&regexp=true&case=true&filter[lang][0]=Rust) shows a large number of diverse reasonable signatures for a `new` method.

changelog: Remove new_ret_no_self from default set of enabled lints
2020-04-08 15:50:24 +02:00
Philipp Krones
2011d9a783
Rollup merge of #5419 - dtolnay:unreadable, r=flip1995
Downgrade unreadable_literal to pedantic

As motivated by #5418. This is the top most commonly suppressed Clippy style lint, which indicates that the community has decided they don't share Clippy's opinion on the best style of this.

I've left the lint in as pedantic, though it could be that "restriction" would be better -- I can see this lint being useful as an opt-in restriction in some codebases.

changelog: Remove unreadable_literal from default set of enabled lints
2020-04-08 15:50:23 +02:00
Philipp Krones
a1e49f962c
Rollup merge of #5415 - nickrtorres:master, r=flip1995
Add new lint for `Result<T, E>.map_or(None, Some(T))`

Fixes #5414

PR Checklist
---
- [x] Followed lint naming conventions (the name is a bit awkward, but it seems to conform)
- [x] Added passing UI tests (including committed .stderr file)
- [x] cargo test passes locally
- [x] Executed cargo dev update_lints
- [x] Added lint documentation
- [x] Run cargo dev fmt

`Result<T, E>` has an [`ok()`](https://doc.rust-lang.org/std/result/enum.Result.html#method.ok) method that adapts a `Result<T,E>` into an `Option<T>`.
It's possible to get around this adapter by writing `Result<T,E>.map_or(None, Some)`.

This lint is implemented as a new variant of the existing [`option_map_none` lint](https://github.com/rust-lang/rust-clippy/pull/2128)
2020-04-08 15:50:20 +02:00
Philipp Krones
5ea4771433
Rollup merge of #5412 - dtolnay:tostring, r=flip1995
Downgrade inefficient_to_string to pedantic

From the [documentation](https://rust-lang.github.io/rust-clippy/master/index.html#inefficient_to_string):

> ```diff
> - ["foo", "bar"].iter().map(|s| s.to_string());
>
> + ["foo", "bar"].iter().map(|&s| s.to_string());
> ```

I feel like saving 10 nanoseconds from the formatting machinery isn't worth asking the programmer to insert extra `&` / `*` noise in the *vast* majority of cases. This is a pedantic lint.

changelog: Remove inefficient_to_string from default set of enabled lints
2020-04-08 15:50:19 +02:00
Philipp Krones
1e1bd519a1
Rollup merge of #5410 - dtolnay:trivially, r=flip1995
Downgrade trivially_copy_pass_by_ref to pedantic

The rationale for this lint is documented as:

> In many calling conventions instances of structs will be passed through registers if they fit into two or less general purpose registers.

I think the purported performance benefits of clippy's recommendation are overstated. This isn't worth asking people to sprinkle code with more `*`​`*`​`&`​`*`​`&` to chase the alleged performance.

This should be a pedantic lint that is disabled by default and opted in if some specific performance sensitive codebase determines that it is worthwhile.

As a reminder, a typical place that a reference to a primitive would come up is if the function is used as a filter. Triggering a performance-oriented lint on this type of code is the definition of pedantic.

```rust
fn filter(_n: &i32) -> bool {
    true
}

fn main() {
    let v = vec![1, 2, 3];
    v.iter().copied().filter(filter).for_each(drop);
}
```

```console
warning: this argument (4 byte) is passed by reference, but would be more efficient if passed by value (limit: 8 byte)
 --> src/main.rs:1:15
  |
1 | fn filter(_n: &i32) -> bool {
  |               ^^^^ help: consider passing by value instead: `i32`
```

changelog: Remove trivially_copy_pass_by_ref from default set of enabled lints
2020-04-08 15:50:17 +02:00
Philipp Krones
935b45db61
Rollup merge of #5409 - dtolnay:letunit, r=flip1995
Downgrade let_unit_value to pedantic

Given that the false positive in #1502 is marked E-hard and I don't have much hope of it getting fixed, I think it would be wise to disable this lint by default. I have had to suppress this lint in every substantial codebase (\>100k line) I have worked in. Any time this lint is being triggered, it's always the false positive case.

The motivation for this lint is documented as:

> A unit value cannot usefully be used anywhere. So binding one is kind of pointless.

with this example:

> ```rust
> let x = {
>     1;
> };
> ```

Sure, but the author would find this out via an unused_variable warning or from `x` not being the type that they need further down. If there ends up being a type error on `x`, clippy's advice isn't going to help get the code compiling because it can only run if the code already compiles.

changelog: Remove let_unit_value from default set of enabled lints
2020-04-08 15:50:16 +02:00