Fix FP for `suspicious_arithmetic_impl` from `suspicious_trait_impl` …
As discussed in #3215, the `suspicious_trait_impl` lint causes too many false positives, as it is complex to find out if binary operations are suspicious or not.
This PR restricts the number of binary operations to at most one, otherwise we don't lint.
This can be seen as very conservative, but at least FP can be reduced to bare minimum.
Fixes: #3215
changelog: limit the `suspicious_arithmetic_impl` lint to one binop, to avoid many FPs
Use `(std::)f64::EPSILON` in the examples as suggested in the lints
`float_cmp(_const)` suggests using `{f32|f64}::EPSILON` and it'd be great if the docs mentioned it.
changelog: none
This commit modifies the `substitute_normalize_and_test_predicates`
query, renaming it to `impossible_predicates` and only checking
predicates which do not require substs. By making this change,
polymorphization doesn't have to explicitly support vtables.
Signed-off-by: David Wood <david@davidtw.co>
Ignore not really redundant clones of ManuallyDrop
"Redundant" clones of `ManuallyDrop` are sometimes used for the side effect of
invoking the clone, without running the drop implementation of the inner type.
In other words, they aren't really redundant. For example, futures-rs crate:
```rust
#[allow(clippy::redundant_clone)] // The clone here isn't actually redundant.
unsafe fn increase_refcount<T: ArcWake>(data: *const ()) {
// Retain Arc, but don't touch refcount by wrapping in ManuallyDrop
let arc = mem::ManuallyDrop::new(Arc::<T>::from_raw(data as *const T));
// Now increase refcount, but don't drop new refcount either
let _arc_clone: mem::ManuallyDrop<_> = arc.clone();
}
```
changelog: Ignore redundant clone lint for ManuallyDrop.
"Redundant" clones of `ManuallyDrop` are sometimes used for the side effect of
invoking the clone, without running the drop implementation of the inner type.
In other words, they aren't really redundant. For example, futures-rs crate:
```rust
#[allow(clippy::redundant_clone)] // The clone here isn't actually redundant.
unsafe fn increase_refcount<T: ArcWake>(data: *const ()) {
// Retain Arc, but don't touch refcount by wrapping in ManuallyDrop
let arc = mem::ManuallyDrop::new(Arc::<T>::from_raw(data as *const T));
// Now increase refcount, but don't drop new refcount either
let _arc_clone: mem::ManuallyDrop<_> = arc.clone();
}
```
Ignore redundant clone lint for ManuallyDrop.
Panic multiple args
changelog: Fixes bug with `panic` lint reported in #5767. I also did the same changes to the lints for `todo`, `unimplemented` and `unreachable`, so those lints should now also detect calls to those macros with a message.
Removing RHS snippet from SHADOW_UNRELATED message.
Fixes#5703
I am not sure if I reinvented the wheel here, but I could not really find a snippet function that did this truncation, so I created the function. Please tell me if there was a more obvious way to do this, I am new here. 😄
changelog: Truncates multi-line RHS in shadow_unrelated message if it has more than 5 lines.
improve advice in iter_nth_zero
fixes#5783
*Please keep the line below*
changelog: For iter_nth_zero, the "use .next()" replacement advice is on the last line of the code snippet, where it is vulnerable to truncation. Display that advice at the beginning instead.
This lint catches cases where the last statement of a closure expecting
an instance of Ord has a trailing semi-colon. It compiles since the
closure ends up return () which also implements Ord but causes
unexpected results in cases such as sort_by_key.
Fixes#5080
reprise: rebase, update and address all concerns
Rename collapsable_if fix suggestion to "collapse nested if block"
The name "try" is confusing when shown as quick fix by rust-analyzer
changelog: Rename `collapsable_if` fix suggestion to "collapse nested if block"
The "use .next()" replacement advice is on the last line of the code snippet,
where it is vulnerable to truncation. Display that advice at the beginning
instead.
closes#5783
Fix out of bounds access by checking length equality BEFORE accessing by index.
Fixes#5780
changelog: fix out of bounds access in unnested_or_patterns lint.
Edit: I did not bother reducing a testcase from `librustc_typeck` crate but I can confirm that with the change the crash no longer occurs.
Move range_minus_one to pedantic
This moves the range_minus_one lint to the pedantic category, so there
will not be any warnings emitted by default. This should work around
problems where the suggestion is impossible to resolve due to the range
consumer only accepting a specific range implementation, rather than the
`RangeBounds` trait (see #3307).
While it is possible to work around this by extracting the boundary into
a variable, I don't think clippy should encourage people to disable or
work around lints, but instead the lints should be fixable. So hopefully
this will help until a proper implementation checks what the range is
used for.
*Please keep the line below*
changelog: move [`range_minus_one`] to pedantic
Some accuracy lints for floating point operations
This will add some lints for accuracy on floating point operations suggested by @clarfon in #2040 (fixes#2040).
These are the remaining lints:
- [x] x.powi(2) => x * x
- [x] x.logN() / y.logN() => x.logbase(y)
- [x] x.logbase(E) => x.log()
- [x] x.logbase(10) => x.log10()
- [x] x.logbase(2) => x.log2().
- [x] x * PI / 180 => x.to_radians()
- [x] x * 180 / PI => x.to_degrees()
- [x] (x + 1).log() => x.log_1p()
- [x] sqrt(x * x + y * y) => x.hypot(y)
changelog: Included some accuracy lints for floating point operations
new lint: match_like_matches_macro
Suggests using the `matches!` macro from `std` where appropriate.
`redundant_pattern_matching` has been moved into the `matches` pass to allow suppressing the suggestion where `is_some` and friends are a better replacement.
changelog: new lint: `match_like_matches_macro`
This moves the range_minus_one lint to the pedantic category, so there
will not be any warnings emitted by default. This should work around
problems where the suggestion is impossible to resolve due to the range
consumer only accepting a specific range implementation, rather than the
`RangeBounds` trait (see #3307).
While it is possible to work around this by extracting the boundary into
a variable, I don't think clippy should encourage people to disable or
work around lints, but instead the lints should be fixable. So hopefully
this will help until a proper implementation checks what the range is
used for.
single_match_else - single expr/stmt else block corner case
One approach to fix#3489.
See discussion in the issue.
changelog: single_match_else - single expr/stmt else block corner case fix
Rollup of 14 pull requests
Successful merges:
- #70563 ([rustdoc] Page hash handling)
- #73856 (Edit librustc_lexer top-level docs)
- #73870 (typeck: adding type information to projection)
- #73953 (Audit hidden/short code suggestions)
- #73962 (libstd/net/tcp.rs: #![deny(unsafe_op_in_unsafe_fn)])
- #73969 (mir: mark mir construction temporaries as internal)
- #73974 (Move A|Rc::as_ptr from feature(weak_into_raw) to feature(rc_as_ptr))
- #74067 (rustdoc: Restore underline text decoration on hover for FQN in header)
- #74074 (Fix the return type of Windows' `OpenOptionsExt::security_qos_flags`.)
- #74078 (Always resolve type@primitive as a primitive, not a module)
- #74089 (Add rust-analyzer to the build manifest)
- #74090 (Remove unused RUSTC_DEBUG_ASSERTIONS)
- #74102 (Fix const prop ICE)
- #74112 (Expand abbreviation in core::ffi description)
Failed merges:
r? @ghost
typeck: adding type information to projection
This commit modifies the Place as follow:
* remove 'ty' from ProjectionKind
* add type information into to Projection
* replace 'ty' in Place with 'base_ty'
* introduce 'ty()' in `Place` to return the final type of the `Place`
* introduce `ty_before_projection()` in `Place` to return the type of
a `Place` before i'th projection is applied
Closes https://github.com/rust-lang/project-rfc-2229/issues/5
Added restriction lint: pattern-type-mismatch
changelog: Added a new restriction lint `pattern-type-mismatch`. This lint is especially helpful for beginners learning about the magic behind pattern matching. (This explanation might be worth to include in the next changelog.)
This commit modifies the Place as follow:
* remove 'ty' from ProjectionKind
* add type information into to Projection
* replace 'ty' in Place with 'base_ty'
* introduce 'ty()' in `Place` to return the final type of the `Place`
* introduce `ty_before_projection()` in `Place` to return the type of
a `Place` before i'th projection is applied
Closes https://github.com/rust-lang/project-rfc-2229/issues/5
Rollup of 13 pull requests
Successful merges:
- #72620 (Omit DW_AT_linkage_name when it is the same as DW_AT_name)
- #72967 (Don't move cursor in search box when using arrows to navigate results)
- #73102 (proc_macro: Stop flattening groups with dummy spans)
- #73297 (Support configurable deny-warnings for all in-tree crates.)
- #73507 (Cleanup MinGW LLVM linkage workaround)
- #73588 (Fix handling of reserved registers for ARM inline asm)
- #73597 (Record span of `const` kw in GenericParamKind)
- #73629 (Make AssocOp Copy)
- #73681 (Update Chalk to 0.14)
- #73707 (Fix links in `SliceIndex` documentation)
- #73719 (emitter: column width defaults to 140)
- #73729 (disable collectionbenches for android)
- #73748 (Add code block to code in documentation of `List::rebase_onto`)
Failed merges:
r? @ghost
Record span of `const` kw in GenericParamKind
Context: this is needed for a fix of https://github.com/rust-lang/rustfmt/issues/4263,
which currently records the span of a const generic param incorrectly
because the location of the `const` kw is not known.
I am not sure how to add tests for this; any guidance in how to do so
would be appreciated 🙂
cmp_owned: handle when PartialEq is not implemented symmetrically
changelog: Handle asymmetrical implementations of PartialEq in [`cmp_owned`].
Fixes#4874
clone_on_copy - add machine applicability
Fix#4826.
Change the applicability of the lint clone_on_copy. Split a test file and run rustfix on the clone_on_copy part.
changelog: clone_on_copy - add machine applicability
Context: this is needed to fix https://github.com/rust-lang/rustfmt/issues/4263,
which currently records the span of a const generic param incorrectly
because the location of the `const` kw is not known.
I am not sure how to add tests for this; any guidance in how to do so
would be appreciated 🙂
#5626: lint iterator.map(|x| x)
changelog: adds a new lint for iterator.map(|x| x) (see https://github.com/rust-lang/rust-clippy/issues/5626)
The code also lints for result.map(|x| x) and option.map(|x| x). Also, I'm not sure if I'm checking for type adjustments correctly and I can't think of an example where .map(|x| x) would apply type adjustments.
Downgrade unnested_or_patterns to pedantic
Even with #5704 fixed, I don't believe it is a safe bet that if someone is using or-patterns anywhere in a codebase then they want to use it as much as possible in the whole codebase. I think it would be reasonable to reevaluate after the feature is stable. I feel that a warn-by-default lint suggesting use of an unstable feature, even if already being used in one place, is questionable.
changelog: Remove unnested_or_patterns from default set of enabled lints
The code should to check that the current expression _is_ the end
expression; not that it's equal to it. The equality check seems very
wasteful in terms of performance.
New lint: suggest `ptr::read` instead of `mem::replace(..., uninitialized())`
resolves: #5575
changelog: improvements to `MEM_REPLACE_WITH_UNINIT`:
- add a new test case in `tests/ui/repl_uninit.rs` to cover the case of replacing with `mem::MaybeUninit::uninit().assume_init()`.
- modify the existing `MEM_REPLACE_WITH_UNINIT` when replacing with `mem::uninitialized` to suggest using `ptr::read` instead.
- lint with `MEM_REPLACE_WITH_UNINIT` when replacing with `mem::MaybeUninit::uninit().assume_init()`
For the following code
```rust
let c = || bar(foo.x, foo.x)
```
We generate two different `hir::Place`s for both `foo.x`.
Handling this adds overhead for analysis we need to do for RFC 2229.
We also want to store type information at each Projection to support
analysis as part of the RFC. This resembles what we have for
`mir::Place`
This commit modifies the Place as follows:
- Rename to `PlaceWithHirId`, where there `hir_id` is that of the
expressioin.
- Move any other information that describes the access out to another
struct now called `Place`.
- Removed `Span`, it can be accessed using the [hir
API](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.span)
- Modify `Projection` to be a strucutre of its own, that currently only
contains the `ProjectionKind`.
Adding type information to projections wil be completed as part of https://github.com/rust-lang/project-rfc-2229/issues/5
Closes https://github.com/rust-lang/project-rfc-2229/issues/3
Co-authored-by: Aman Arora <me@aman-arora.com>
Co-authored-by: Roxane Fruytier <roxane.fruytier@hotmail.com>
Stabilize Option::zip
This PR stabilizes the following API:
```rust
impl<T> Option<T> {
pub fn zip<U>(self, other: Option<U>) -> Option<(T, U)>;
}
```
This API has real world usage as seen in <https://grep.app/search?q=-%3E%20Option%3C%5C%28T%2C%5Cs%3FU%5C%29%3E®exp=true&filter[lang][0]=Rust>.
The `zip_with` method is left unstably as this API is kinda niche
and it hasn't received much usage in Rust repositories on GitHub.
cc #70086
Clean up type alias impl trait implementation
- Removes special case for top-level impl trait
- Removes associated opaque types
- Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types.
- Handle lifetimes in type alias impl trait more uniformly with other parameters
cc #69323
cc #63063Closes#57188Closes#62988Closes#69136Closes#73061
let_and_return: avoid "does not live long enough" errors
EDIT: Add #3324 to the list of fixes
<details>
<summary>Description of old impl</summary>
<br>
Avoid suggesting turning the RHS expression of the last statement into the block tail expression if a temporary borrows from a local that would be destroyed before.
This is my first incursion into MIR so there's probably room for improvement!
</details>
Avoid linting if the return type of some method or function called in the last statement has a lifetime parameter.
changelog: Fix false positive in [`let_and_return`]
Fixes#3792Fixes#3324
Make `PolyTraitRef::self_ty` return `Binder<Ty>`
This came up during review of #71618. The current implementation is the same as a call to `skip_binder` but harder to audit. Make it preserve binding levels and add a call to `skip_binder` at all use sites so they can be audited as part of #72507.
Give corrected code
This PR adds corrected code for doc examples.
I did this in several commits to facilitate review.
Don't hesitate to tell me if I forgot some.
Also, sometimes I felt it was not necessary to give corrected code, but I maybe wrong.
fixes: #4829
changelog: Improve documentation examples across multiple lints.
New lint: iter_next_slice
Hello, this is a work-in-progress PR for issue: https://github.com/rust-lang/rust-clippy/issues/5572
I have implemented lint to replace `iter().next()` for `slice[index..]` and `array` with `get(index)` and `get(0)` respectively. However since I made a lot of changes, I would like to request some feedback before continuing so that I could fix mistakes.
Thank you!
---
changelog: implement `iter_next_slice` lint and test, and modify `needless_continues`, `for_loop_over_options_result` UI tests since they have `iter().next()`
len_zero: skip ranges if feature `range_is_empty` is not enabled
If the feature is not enabled, calling `is_empty()` on a range is ambiguous. Moreover, the two possible resolutions are unstable methods, one inherent to the range and the other being part of the `ExactSizeIterator` trait.
Since `len_zero` only checks for existing `is_empty()` inherent methods, we only take into account the `range_is_empty` feature.
Related: https://github.com/rust-lang/rust/issues/48111#issuecomment-445132965
changelog: len_zero: avoid linting ranges without #![feature(range_is_empty)]
Fixes: #3807
Extend useless conversion
This PR extends `useless_conversion` lint with `TryFrom` and `TryInto`
fixes: #5344
changelog: Extend `useless_conversion` with `TryFrom` and `TryInto`
Make empty_line_after_outer_attr an early lint
Fixes#5567
Unfortunately I couldn't find a way to reproduce the issue without syn/quote. Considering that most real-world macros use syn and/or quote, I think it's okay to pull them in anyway.
changelog: Fix false positive in [`empty_line_after_outer_attr`]
reversed_empty_ranges: add suggestion for &slice[N..N]
As discussed in the issue thread, the user accepted this solution. Let me know if this is what we want, or if changing the way we lint the N..N case is prefered.
changelog: reversed_empty_ranges: add suggestion for &slice[N..N]
Closes#5628
ptr_arg: honor `allow` attribute on arguments
The `intravisit::Visitor` impl for `LateContextAndPass` only takes into account the attributes of a function parameter inside the `check_param` method. `ptr_arg` starts its heuristics at `check_item` / `check_impl_item` / `check_trait_item`, so the `allow` is not taken into account automatically.
changelog: ptr_arg: honor `allow` attribute on arguments
Fixes#5644
new_without_default: do not suggest deriving
---
changelog: do not suggest deriving `Default` in `new_without_default`
This commit changes the behavior of the `new_without_default` lint to not suggest deriving `Default`. This suggestion is misleading if the `new` implementation does something different than what a derived `Default` implementation would do, because then the two methods would not be equivalent.
Instead, the `can_derive_default` check is removed, and we always suggest implementing `Default` in terms of `new()`.
Clarify the documentation of the `unnecessary_mut_passed` lint
fixes#5433 by replacing "giving" with "passing"
changelog: Clarifies documentation for `unnecessary_mut_passed`
Add to the list of words clippy::doc_markdown ignores
"TypeScript" is the only one of these I actually ran into organically; I can remove the others if they're too much.
changelog: Add to the list of words `clippy::doc_markdown` ignores
New lint: `match_wildcard_for_single_variants`
changelog: Added a new lint match_wildcard_for_single_variants to warn on enum matches where a wildcard is used to match a single variant
Closes#5556
Rename lint `identity_conversion` to `useless_conversion`
Lint name `identity_conversion` was misleading, so this PR renames it to `useless_conversion`.
As decision has not really came up in the issue comments, this PR will probably need discussion.
fixes#3106
changelog: Rename lint `identity_conversion` to `useless_conversion`
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`
Literal error reporting cleanup
While doing some performance work, I noticed some code duplication in `librustc_parser/lexer/mod.rs`, so I cleaned it up.
This PR is probably best reviewed commit by commit.
I'm not sure what the API stability practices for `librustc_lexer` are. Four public methods in `unescape.rs` can be removed, but two are used by clippy, so I left them in for now.
I could open a PR for Rust-Analyzer when this one lands.
But how do I open a PR for clippy? (Git submodules are frustrating to work with)
identity_op: allow `1 << 0`
I went for accepting `1 << 0` verbatim instead of something more general as it seems to be what everyone in the issue thread needed.
changelog: identity_op: allow `1 << 0` as it's a common pattern in bit manipulation code.
Fixes#3430
Downgrade useless_let_if_seq to nursery
I feel that this lint has the wrong balance of incorrect suggestions for a default-enabled lint.
The immediate code I faced was something like:
```rust
fn main() {
let mut good = do1();
if !do2() {
good = false;
}
if good {
println!("good");
}
}
fn do1() -> bool { println!("1"); false }
fn do2() -> bool { println!("2"); false }
```
On this code Clippy calls it unidiomatic and suggests the following diff, which has different behavior in a way that I don't necessarily want.
```diff
- let mut good = do1();
- if !do2() {
- good = false;
- }
+ let good = if !do2() {
+ false
+ } else {
+ do1()
+ };
```
On exploring issues filed about this lint, I have found that other users have also struggled with inappropriate suggestions (https://github.com/rust-lang/rust-clippy/issues/4124, https://github.com/rust-lang/rust-clippy/issues/3043, https://github.com/rust-lang/rust-clippy/issues/2918, https://github.com/rust-lang/rust-clippy/issues/2176) and suggestions that make the code worse (https://github.com/rust-lang/rust-clippy/issues/3769, https://github.com/rust-lang/rust-clippy/issues/2749). Overall I believe that this lint is still at nursery quality for now and should not be enabled.
---
changelog: Remove useless_let_if_seq from default set of enabled lints
Reversed empty ranges
This lint checks range expressions with inverted limits which result in empty ranges. This includes also the ranges used to index slices.
The lint reverse_range_loop was covering iteration of reversed ranges in a for loop, which is a subset of what this new lint covers, so it has been removed. I'm not sure if that's the best choice. It would be doable to check in the new lint that we are not in the arguments of a for loop; I went for removing it because the logic was too similar to keep them separated.
changelog: Added reversed_empty_ranges lint that checks for ranges where the limits have been inverted, resulting in empty ranges. Removed reverse_range_loop which was covering a subset of the new lint.
Closes#4192Closes#96
Extend example for the `unneeded_field_pattern` lint
Current example is incorrect (or pseudo-code) because a struct name is omitted. I have used the code from the tests instead. Perhaps this example can be made less verbose, but I think it is more convenient to see a "real" code as an example.
---
changelog: extend example for the `unneeded_field_pattern` lint
Fix match on vec items: match on vec[..]
- Added new tests
- Fixed false positive when matching on full range, which will never panic
Closes#5551
changelog: fix match_on_vec_items when matching full range
Fix `unnecessary_unwrap` lint when checks are done in parameters
Fixes a false positive in `unnecessary_unwrap` lint when checks are done in macro parameters.
FIxes#5174
changelog: Fixes a false positive in `unnecessary_unwrap` lint when checks are done in macro parameters.
Fix FP on while-let-on-iterator
- fix `is_refutable` for slice patterns
- fix `is_refutable` for bindings
- add some TODO-s for cases, which can not be fixed easily
fixes#3780
changelog: fix FP on while-let-on-iterator for arrays and bindings
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
Fix the bugs of `manual_memcpy`, simplify the suggestion and refactor it
While I’m working on the long procrastinated work to expand `manual_memcpy`(#1670), I found a few minor bugs and probably unidiomatic or old coding style. There is a brief explanation of changes to the behaviour this PR will make below. And, I have a questoin: do I need to add tests for the first and second fixed bugs? I thought it might be too rare cases to include the tests for those. I added for the last one though.
* Bug fix
* It negates resulted offsets (`src/dst_offset`) when `offset` is subtraction by 0. This PR will remove any subtraction by 0 as a part of minification.
```rust
for i in 0..5 {
dst[i - 0] = src[i];
}
```
```diff
warning: it looks like you're manually copying between slices
--> src/main.rs:2:14
|
LL | for i in 0..5 {
- | ^^^^ help: try replacing the loop by: `dst[..-5].clone_from_slice(&src[..5])`
+ | ^^^^ help: try replacing the loop by: `dst[..5].clone_from_slice(&src[..5])`
|
```
* It prints `RangeTo` or `RangeFull` when both of `end` and `offset` are 0, which have different meaning. This PR will print 0. I could reject the cases `end` is 0, but I thought I won’t catch other cases `reverse_range_loop` will trigger, and it’s over to catch every such cases.
```rust
for i in 0..0 {
dst[i] = src[i];
}
```
```diff
warning: it looks like you're manually copying between slices
--> src/main.rs:2:14
|
LL | for i in 0..0 {
- | ^^^^ help: try replacing the loop by: `dst.clone_from_slice(&src[..])`
+ | ^^^^ help: try replacing the loop by: `dst[..0].clone_from_slice(&src[..0])`
|
```
* it prints four dots when `end` is `None`. This PR will ignore any `for` loops without `end` because a `for` loop that takes `RangeFrom` as its argument and contains indexing without the statements or the expressions that end loops such as `break` will definitely panic, and `manual_memcpy` should ignore the loops with such control flow.
```rust
fn manual_copy(src: &[u32], dst: &mut [u32]) {
for i in 0.. {
dst[i] = src[i];
}
}
```
```diff
-warning: it looks like you're manually copying between slices
- --> src/main.rs:2:14
- |
-LL | for i in 0.. {
- | ^^^ help: try replacing the loop by: `dst[....].clone_from_slice(&src[....])`
- |
```
* Simplification of the suggestion
* It prints 0 when `start` or `end` and `offset` are same (from #3323). This PR will use `RangeTo`
changelog: fixed the bugs of `manual_memcpy` and also simplify the suggestion.
Current example is incorrect (or pseudo-code) because a struct name is omitted. I have used the code from the tests instead. Perhaps this example can be made less verbose, but I think it is more convenient to see a "real" code as an example.
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`
- Show just one error message with multiple suggestions in case of
using multiple times an OS in target family position
- Only suggest #[cfg(unix)] when the OS is in the Unix family
- Test all the operating systems
Don't trigger while_let_on_iterator when the iterator is recreated every iteration
r? @phansch
Fixes#1654
changelog: Fix false positive in [`while_let_on_iterator`]
Downgrade match_bool to pedantic
I don't quite buy the justification in https://rust-lang.github.io/rust-clippy/. The justification is:
> It makes the code less readable.
In the Rust codebases I've worked in, I have found people were comfortable using `match bool` (selectively) to make code more readable. For example, initializing struct fields is a place where the indentation of `match` can work better than the indentation of `if`:
```rust
let _ = Struct {
v: {
...
},
w: match doing_w {
true => ...,
false => ...,
},
x: Nested {
c: ...,
b: ...,
a: ...,
},
y: if doing_y {
...
} else { // :(
...
},
z: ...,
};
```
Or sometimes people prefer something a bit less pithy than `if` when the meaning of the bool doesn't read off clearly from the condition:
```rust
if set.insert(...) {
... // ???
} else {
...
}
match set.insert(...) {
// set.insert returns false if already present
false => ...,
true => ...,
}
```
Or `match` can be a better fit when the bool is playing the role more of a value than a branch condition:
```rust
impl ErrorCodes {
pub fn from(b: bool) -> Self {
match b {
true => ErrorCodes::Yes,
false => ErrorCodes::No,
}
}
}
```
And then there's plain old it's-1-line-shorter, which means we get 25% more content on a screen when stacking a sequence of conditions:
```rust
let old_noun = match old_binding.is_import() {
true => "import",
false => "definition",
};
let new_participle = match new_binding.is_import() {
true => "imported",
false => "defined",
};
```
Bottom line is I think this lint fits the bill better as a pedantic lint; I don't think linting on this by default is justified.
changelog: Remove match_bool from default set of enabled lints
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.
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
Fix issue #2907.
Update the "borrow box" lint to avoid recommending the following
conversion:
```
// Old
pub fn f(&mut Box<T>) {...}
// New
pub fn f(&mut T) {...}
```
Given a mutable reference to a box, functions may want to change
"which" object the Box is pointing at.
This change avoids recommending removing the "Box" parameter
for mutable references.
changelog: Don't trigger [`borrow_box`] lint on `&mut Box` references
Cleanup: `node_id` -> `hir_id`
This removes some more `node_id` terminology from Clippy and replaces one occurrence of `as_local_node_id` with `as_local_hir_id`, which should be doing the same for that particular case.
changelog: none
Update the "borrow box" lint to avoid recommending the following
conversion:
```
// Old
pub fn f(&mut Box<T>) {...}
// New
pub fn f(&mut T) {...}
```
Given a mutable reference to a box, functions may want to change
"which" object the Box is pointing at.
This change avoids recommending removing the "Box" parameter
for mutable references.
add lint futures_not_send
changelog: add lint futures_not_send
fixes#5379
~Remark: one thing that can (should?) still be improved is to directly include the error message from the `Send` check so that the programmer stays in the flow. Currently, getting the actual error message requires a restructuring of the code to make the `Send` constraint explicit.~
It now shows all unmet constraints for allowing the Future to be Send.
Fixes issue #4892.
First contribution here 😊 ! Do not hesitate to correct me.
This PR is related to issue #4892 .
# Summary
```rust
-literal.method_call(args)
```
The main idea is to not trigger `clippy::precedence` when the method call is an odd function.
# Example
```rust
// should trigger lint
let _ = -1.0_f64.abs() //precedence of method call abs() and neg ('-') is ambiguous
// should not trigger lint
let _ = -1.0_f64.sin() // sin is an odd function => -sin(x) = sin(-x)
```
# Theory
Rust allows following literals:
- char
- string
- integers
- floats
- byte
- bool
Only integers/floats implements the relevant `std::ops::Neg`.
Following odd functions are implemented on i[8-128] and/or f[32-64]:
- `asin`
- `asinh`
- `atan`
- `atanh`
- `cbrt`
- `fract`
- `round`
- `signum`
- `sin`
- `sinh`
- `tan`
- `tanh `
- `to_degrees`
- `to_radians`
# Implementation
As suggested by `flip1995` in [comment](https://github.com/rust-lang/rust-clippy/issues/4892#issuecomment-568249683), this PR add a whitelist of odd functions and compare method call to the the whitelist before triggering lint.
changelog: Don't trigger [`clippy::precedence`] on odd functions.
question_mark: don't add `as_ref()` for a call expression
If a call returns a `!Copy` value, it does so regardless of whether `as_ref()` is added. For example, `foo.into_option().as_ref()?` can be simplified to `foo.into_option()?`.
---
changelog: Improved `question_mark` lint suggestion so that it doesn't add redundant `as_ref()`
Do not lint in macros for match lints
Don't lint in macros for match lints, more precisely in `check_pat` and `check_local` where it was not the case.
changelog: none
fixes: #5362
large_enum_variant: Report sizes of variants
This reports the sizes of the largest and second-largest variants.
Closes#5459
changelog: `large_enum_variant`: Report the sizes of the largest and second-largest variants.
Disallow bit-shifting in integer_arithmetic
Make the `integer_arithmetic` lint detect all the operations that are defined as being capable of overflow in the [Rust Reference](https://doc.rust-lang.org/reference/expressions/operator-expr.html#overflow), by also linting for bit-shifting operations (`<<`, `>>`).
changelog: Disallow bit-shifting in `integer_arithmetic`
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
Add lint for explicit deref and deref_mut method calls
This PR adds the lint `explicit_deref_method` that suggests replacing `deref()` and `deref_mut()` with `&*a` and `&mut *a`.
It doesn't lint inside macros.
This PR is the continuation of #3258.
changelog: Add lint `explicit_deref_method`.
Fixes: #1566
Add lint for float in array comparison
Fixes#4277
changelog:
- Added new handler for expression of index kind (e.g. `arr[i]`). It returns a constant when both array and index are constant, or when the array is constant and all values are equal.
- Trigger float_cmp and float_cmp_const lint when comparing arrays. Allow for comparison when one of the arrays contains only zeros or infinities.
- Added appropriate tests for such cases.
Refactor: Use rustc's `match_def_path`
This replaces our match_def_path implementation with the rustc one.
Note that we can't just use it in all call sites because of the
`&[&str]` / `&[Symbol]` difference in Clippy/rustc.
changelog: none
This replaces our match_def_path implementation with the rustc one.
Note that we can't just use it in all call sites because of the
`&[&str]` / `&[Symbol]` difference in Clippy/rustc.
Make use of more diagnostic items
This makes use of some (not all) already existing diagnostic items. Specifically:
* 79982a2: `core::mem::uninitialized`, `core::mem::zeroed`, `alloc::sync::Arc`, `alloc::sync::Rc`
* 83874d0: `Option` and `Result`
cc #5393
changelog: none
Fixes#5405: redundant clone false positive with arrays
Check whether slice elements implement Copy before suggesting to drop
the clone method
changelog: add a check for slice indexing on redundant_clone lint
Update documentation for new_ret_no_self
changelog: Update documentation for lint new_ret_no_self to reflect that the return type must only contain `Self`, not be `Self`
The lint was changed to be more lenient than the documentation implies in PR #3338 (Related issue #3313)
Change the existing hex bit mask (`0x1111`) to a binary one (`0b1111`).
The former does not seem to have anything to do with trailing zeros and is
probably a typo.
This change adds a check to the `inconsistent_digit_grouping` to add a check for
NumericLiterals that follow the UUID format of 8-4-4-4-12.
If the NumericLiteral matches the UUID format, no further inconsistent grouping checks
will be performed.
Closes#5431
Check for clone-on-copy in argument positions
Earlier if arguments to method calls matched the above pattern they were
not reported. This patch ensures such arguments are checked as well.
Fixes#5436
changelog: apply clone_on_copy lint to func args as well
Earlier if arguments to method calls matched the above pattern they were
not reported. This patch ensures such arguments are checked as well.
Fixes#5436
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
Check fn header along with decl when suggesting to implement trait
When checking for functions that are potential candidates for trait
implementations check the function header to make sure modifiers like
asyncness, constness and safety match before triggering the lint.
Fixes#5413, #4290
changelog: check fn header along with decl for should_implement_trait
When checking for functions that are potential candidates for trait
implementations check the function header to make sure modifiers like
asyncness, constness and safety match before triggering the lint.
Fixes#5413, #4290
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
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)
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
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
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
Fix update_lints
This fixes a bug in update_lints, where `internal` lints were not registered properly. This also cleans up some code. For example: The code generation functions no longer filter the lints the are given. This is now the task of the caller. This way, it is more obvious in the `replace_in_file` calls which lints will be included in which part of a file.
This also turns the lint modules private. There is no need for them to be public, since shared code should be in the utils module anyway.
And last but not least, this fixes the `register_lints` code generation, so also internal lints get registered.
changelog: none
Result<T, E> has an `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)
useless Rc<Rc<T>>, Rc<Box<T>>, Rc<&T>, Box<&T>
refers to #2394
changelog: Add lints for Rc<Rc<T>> and Rc<Box<T>> and Rc<&T>, Box<&T>
this is based on top of another change #5310 so probably should go after that one.
Downgrade option_option to pedantic
Based on a search of my work codebase (\>500k lines) for `Option<Option<`, it looks like a bunch of reasonable uses to me. The documented motivation for this lint is:
> an optional optional value is logically the same thing as an optional value but has an unneeded extra level of wrapping
which seems a bit bogus in practice. For example a typical usage would look like:
```rust
let mut host: Option<String> = None;
let mut port: Option<i32> = None;
let mut payload: Option<Option<String>> = None;
for each field {
match field.name {
"host" => host = Some(...),
"port" => port = Some(...),
"payload" => payload = Some(...), // can be null or string
_ => return error,
}
}
let host = host.ok_or(...)?;
let port = port.ok_or(...)?;
let payload = payload.ok_or(...)?;
do_thing(host, port, payload)
```
This lint seems to fit right in with the pedantic group; I don't think linting on occurrences of `Option<Option<T>>` by default is justified.
---
changelog: Remove option_option from default set of enabled lints
Lint unnamed address comparisons
Functions and vtables have an insignificant address. Attempts to compare such addresses will lead to very surprising behaviour. For example: addresses of different functions could compare equal; two trait object pointers representing the same object and the same type could be unequal.
Lint against unnamed address comparisons to avoid issues like those in rust-lang/rust#69757 and rust-lang/rust#54685.
changelog: New lints: [`fn_address_comparisons`] [#5294](https://github.com/rust-lang/rust-clippy/pull/5294), [`vtable_address_comparisons`] [#5294](https://github.com/rust-lang/rust-clippy/pull/5294)
`unused_self` false positive
fixes#5351
Remove the for loop in `unused_self` so that lint enabled for one method doesn't trigger on another method.
changelog: Fix false positive in `unused_self` around lint gates on impl items
Move verbose_file_reads to restriction
cc #5368
Using `File::read` instead of `fs::read_to_end` does make sense in multiple cases, so this lint is rather restriction, than complexity
changelog: Move [`verbose_file_reads`] to restriction
Lint for `pub(crate)` items that are not crate visible due to the visibility of the module that contains them
changelog: Add `redundant_pub_crate` lint
Closes#5274.
Fix single binding closure
Fix the `match_single_binding` lint when triggered inside a closure.
Fixes: #5347
changelog: Improve suggestion for [`match_single_binding`]
Improvement: Don't show function body in needless_lifetimes
Changes the span on which the lint is reported to point to only the
function return type instead of the entire function body.
Fixes#5284
changelog: none
Extend `redundant_clone` to the case that cloned value is not consumed
Fixes#5303.
---
changelog: Extend `redundant_clone` to the case that cloned value is not consumed
add lint on File::read_to_string and File::read_to_end
Adds lint `verbose_file_reads` which checks for use of File::read_to_end and File::read_to_string.
Closes https://github.com/rust-lang/rust-clippy/issues/4916
changelog: add lint on File::{read_to_end, read_to_string}
redundant_pattern: take binding (ref, ref mut) into account in suggestion
fixes#5271
changelog: redundant_pattern: take binding (ref, ref mut) into account in suggestion (#5271)
Fix match single binding when in a let stmt
Fix bad suggestion when `match_single_binding` lints when inside a local (let) statement.
Fixes#5267
changelog: none
Resolve false positives of unnecessary_cast for non-decimal integers
This PR resolves false positives of `unnecessary_cast` for hexadecimal integers to floats and adds a corresponding test case.
Fixes: #5220
changelog: none
Add lint for .. use in fully binded struct
This PR adds the lint `match-wild-in-fully-binded-struct` to prevent the use of the `..` pattern when all fields of the struct are already binded.
Fixes: #638
changelog: Add [`rest_pat_in_fully_bound_structs`] lint to warn against the use of `..` in fully binded struct
Detect usage of custom floating-point abs implementation
Closes#5224
changelog: Enhance [`suboptimal_flops`] lint to detect manual implementations of the `abs` method
Whitelist unused attribute for use items.
This PR whitelists the `unused` attribute with `use` items and adds a corresponding test case.
Fixes: #5229
changelog: none
Add lint to detect floating point operations that can be computed more
accurately at the cost of performance. `cbrt`, `ln_1p` and `exp_m1`
library functions call their equivalent cmath implementations which is
slower but more accurate so moving checks for these under this new lint.
Merge the accuracy and efficiency lints into a single lint that
checks for improvements to accuracy, efficiency and readability
of floating-point expressions.
Move check for lossy whole-number floats out of `excessive_precision`
changelog: Add new lint `lossy_float_literal` to detect lossy whole number float literals and move it out of `excessive_precision` again.
Fixes#5201
Make it possible to correctly indent snippet_block snippets
This adds a `indent_relative_to` arg to the `{snippet,expr}_block` functions. This makes it possible to keep the correct indentation of block like suggestions.
In addition, this makes the `trim_multiline` function private and adds a `indent_of` function, to get the indentation of the first line of a span.
The suggestion of `needless_continue` cannot be made auto applicable, since it would be also necessary to remove code following the linted expression. (Well, maybe it is possible, but I don't know how to do it. Expanding the suggestion span to the last expression, that should be removed didn't work)
changelog: Improve suggestions, when blocks of code are involved
Port mitsuhiko's excessive bools lints
Closes#4 .
changelog: add `struct_excessive_bools` and `fn_params_excessive_bools` lints.
I moved is_trait_impl_item check because at first I implemented it as a late pass for some reason but then I realized it's actually an early lint. But it's a useful function to have, should I move it into a separate pr?
Do not lint `unnecessary_unwrap` in external macros
Fixes#5131
I think we shouldn't lint `{panicking, unnecessary}_unwrap` in macros, not just `assert!`.
changelog: Fix false positive in `unnecessary_unwrap`
Use `checked_sub` to avoid index out of bounds
(Fixes) #4681 (possibly)
The issue likely occurs due to `lit_snip.len() < suffix.len() + 1`. You can see similar backtrace to change it to `lit_snip.len() - suffix.len() - 1000` or something then run `cargo test --release`.
But I couldn't come up with the test so I'd leave the issue open if we want.
changelog: Fix potential ICE in `misc_early`
Tweak documentation in `multiple_crate_versions`
This example isn't reproducible now since `ctrlc` upgrades `winapi` to `0.3.x` in `3.1.1`. We should pin their versions to trigger lint correctly.
changelog: none
Fix syntax highlighting of code fences
The documentation for RESULT_EXPECT_USED includes this code:
let res: Result<usize, ()> = Ok(1);
res?;
# Ok::<(), ()>(())
Because the code fence didn't start with `rust`, the code wasn't highlighted and the line starting with `#` was displayed on the website. This is now fixed.
EDIT: I noticed that highlighting for some other lints is broken as well. It only works if the code fence looks like this:
````markdown
```rust
// ..
```
````
However, many code blocks were ignored. I un-ignored most code blocks and made them compile by adding hidden code with `#`. While doing so, I found two mistakes:
```rust
opt.map_or(None, |a| a + 1)
// instead of
opt.map_or(None, |a| Some(a + 1))
```
and
```rust
fn as_str(self) -> &str
// instead of
fn as_str(self) -> &'static str
```
changelog: none
The documentation for RESULT_EXPECT_USED includes this code:
let res: Result<usize, ()> = Ok(1);
res?;
# Ok::<(), ()>(())
Because the code fence didn't start with `rust`, the code wasn't highlighted and the line starting with `#` was displayed on the website. This is now fixed.
Clean up `span_lint` in `methods/mod.rs`
Uses `span_help_and_lint` instead of `span_lint` and `span_lint_and_sugg` instead of `span_lint_and_then`.
changelog: none
dont fire `possible_missing_comma` if intendation is present
Closes#4399
changelog: dont fire `possible_missing_comma` if intendation is present
I suspect there is already a utils function for indentation (but searching indent didn't yield a function for that), and my solution is certainly not universal, but it's probably the best we can do.
Detect usage of invalid atomic ordering in memory fences
Detect usage of `core::sync::atomic::{fence, compiler_fence}` with `Ordering::Relaxed` and suggest valid alternatives.
changelog: Extend `invalid_atomic_ordering` to lint memory fences
Fixes#5026
Avoid mut_key on types of unknown layout
This fixes#5020 by requiring a known layout for the key type before linting. Edit: This fixes#5043, too.
changelog: none
Keep the ordering in `nonminimal_bool` lint
I believe it shouldn't cause any regression but feel free to let me know if you have a doubtful example.
Also, splits up `booleans` ui test.
Fixes#5045
changelog: none
Match wild err arm improvements
This lint should trigger on other identifiers which have `_` prefix (such as `_e`) and only if they are unused in the panic block.
_Note_: the `is_unused` function is greatly inspired from `pat_is_wild` function in [loops lints](43ac9416d9/clippy_lints/src/loops.rs (L1689)).
I've been considering doing some refactoring, maybe in utils. Maybe this PR or a new one. What do you think ?
fixes#5024
changelog: none
New lint: pats_with_wild_match_arm
Wildcard use with other pattern in same match arm.
The wildcard covers other(s) pattern(s) as it will match anyway.
changelog: add new lint when multiple patterns (including wildcard) are used in a match arm.
Fixes#4640.
Fix redundant_clone lint not working with PathBuf and OsString
https://github.com/rust-lang/rust-clippy/pull/4825 diabled MIR optimization in clippy, including `rustc_mir::transform::InstCombine` which reduces `&(*x)` to `x`. This PR tries to unwrap `&*` when looking into `mir::Rvalue`s.
Fixes#5014.
---
changelog: fixed `redundant_clone` lint not working with `PathBuf` and `OsString`
Move `transmute_float_to_int` lint to `complexity`
`transmute_float_to_int` lint was accidentally added to nursery so moving it to the complexity group.
changelog: Move `transmute_float_to_int` out of nursery
Detect usage of invalid atomic ordering modes such as
`Ordering::{Release, AcqRel}` in atomic loads and
`Ordering::{Acquire, AcqRel}` in atomic stores.
Use `mem::take` instead of `mem::replace` when applicable
`std::mem::take` can be used to replace a value of type `T` with `T::default()` instead of `std::mem::replace`.
Fixes issue #4871
changelog: Added lint for [`mem_replace_with_default`]
Fix ICE on `unsound_collection_transmute`
Fixes#4968
Check if `Ty`s are normalizable. It might show hidden false negative, I'm not sure.
Also, the regression tests are placed on two dirs, so move them to `/crashes`. I think it will be easier to find the right place.
changelog: Fix ICE on `unsound_collection_transmute`
Currently `replace_consts` lint applies within match patterns but
the suggestion is incorrect as function calls are disallowed in
them. To fix this we prevent the lint from firing within patterns.
Fix `replace_consts` lint documentation
`replace_consts` lint no longer lints for the usage of
`ATOMIC_{SIZE}_INIT` and `ONCE_INIT` so removing any
occurences of them in the documentation.
changelog: Update `replace_consts` lint documentation
new lint: mutable_key_type
This fixes#732 - well, partly, it doesn't adress `Hash` impls, but the use of mutable types as map keys or set members
changelog: add `mutable_key_type` lint
r? @flip1995
Add `let_underscore_must_use` lint
changelog: closes#4812 , added a new `let_underscore_must_use` lint, moved `is_must_use_ty` to utils, added `is_must_use_fn` util function
Fix `map_clone` false positive
Don't lint when the item type is not a reference. `copied` only applies to references.
changelog: Fix `map_clone` false positive
Currently the cognitive complexity lint spans the entire function
body making it really difficult to read and refactor the code in
editors. To fix this we reduce the lint span to the function name.
Move `iterator_step_by_zero` and correct the documentation
Move `iterator_step_by_zero` and correct the documentation.
changelog: Corrected `iterator_step_by_zero` documentation
Currently `cmp_nan` lint doesn't detect comparisons with NaN's
if the operands are consts variables so to fix this we evaluate
the const variables first before testing for NaN.
Fix false positive with cast_sign_loss lint
`cast_sign_loss` lint incorrectly suggests that the result of `checked_abs`, `rem_euclid` and `checked_rem_euclid` cannot be casted to an unsigned integer without loss.
Fixes#4818#4764#4743
changelog: Fix false positives in `cast_sign_loss` lint
The Rust Book recommends that functions that return a `Result` type have
a doc comment with an `# Errors` section describing the kind of errors
that can be returned
(https://doc.rust-lang.org/book/ch14-02-publishing-to-crates-io.html#commonly-used-sections).
This change adds a lint to enforce this. The lint is allow by default;
it can be enabled with `#![warn(clippy::missing_errors_doc)]`.
Closes#4854.
`cast_sign_loss` lint incorrectly suggests that the result of
`checked_abs`, `rem_euclid` and `checked_rem_euclid` cannot
be casted to an unsigned integer without loss.
Fix FP in manual_swap lint with slice-like types
Fixes#4853
changelog: Fix FP in [`manual_swap`] lint with slice-like types and make it auto applicable
This utilizes https://github.com/rust-lang/rust/pull/60584 by setting
our own `panic_hook` and pointing to our own issue tracker instead of
the rustc issue tracker.
This also adds a new internal lint to test the ICE message.
**Potential downsides**
* This essentially copies rustc's `report_ice` function as
`report_clippy_ice`. I think that's how it's meant to be implemented, but
maybe @jonas-schievink could have a look as well =)
The downside of more-or-less copying this function is that we have to
maintain it as well now.
The original function can be found [here][original].
* `driver` now depends directly on `rustc` and `rustc_errors`
Closes#2734
[original]: 59367b074f/src/librustc_driver/lib.rs (L1185)
Move use_self to nursery
Closes#4859
We have a lot of false positives in this lint, so I think it makes sense
to move this to the nursery until they are resolved.
changelog: Move `use_self` lint to nursery, due to many false positives
Closes#4859
We have a lot of false positives in this lint, so I think it makes sense
to move this to the nursery until they are resolved.
changelog: Move `use_self` lint to nursery, due to many false positives
Literal Representation Restructure
This pull request restructures the literal_representation module to be easier to understand and maintain. I split the changes into a lot of commits to make reviewing easier.
changelog: none
Fix false positive in derive_hash_xor_eq
This fixes a false positive in derive_hash_xor_eq where the lint was
triggering on user-defined traits called `Hash`.
changelog: Fix false positive in `derive_hash_xor_eq`
Fixes#4658
Fix check_infinite_loop (while_immutable_condition) by checking for break or return inside loop body
changelog: Fix check_infinite_loop (while_immutable_condition) by checking for break or return inside loop body
fixes#4648
Run ./util/dev
Revert changelog entry
Rename lint to same_functions_in_if_condition and add a doc example
Add testcases with different arg in fn invocation
added documentation
minor style fix
change as to ::from
add ignore to doc
include threshold in lint message/make suggestion more apparent/use Scalar api instead of matching
style fix
shange snippet_opt to snippet
Only store valid suffixes (and not mistyped suffixes) in DigitInfo.
Check for mistyped suffixes later and not when DigitInfo is created.
This opens the door to more sophisticated mistyped suffix checks later.
Fix false positive in explicit_counter_loop lint
When the counter was used in a closure after the loop the lint didn't detect the
usage of the counter correctly.
changelog: Fix false positive in `explicit_counter_loop`
Fixes#4732
restriction lint for `std::process::exit`
Addition to #4655 - adds the lint checking for `std::process::exit`
changelog: add restriction lint for `std::process::exit`
Fix Deprecated lints don't expand
### Move doc comments inside of declare_deprecated_lint macros so that they are picked up by lintlib.py
### fixes#4748
Unable to `cargo test` locally (I'm on NixOS, and keep getting errors that are similar to those #4714 might solve) but I have verified that all deprecated lints can now be expanded like other lints.
changelog: Show deprecated lints in lint documentation again
Specifically, this revises the clippy integration to utilize a new
callback to register its lints, as the prior editing of lint store in
Session is no longer possible.
Add lint for debug_assert_with_mut_call
closes#1526
**What does not work:**
* detecting a mut call in the format string itself, e.g. `debug_assert!(false, "{}", vec![1].pop())`
* detecting `*mut T` usage (pointer)
---
changelog: add new lint `debug_assert_with_mut_call`
Fix suggestion of `explicit_counter_loop`
changelog: In the suggestion of `explicit_counter_loop`, if the `for` loop argument doesn't implement `Iterator`, then we suggest `x.into_iter().enumerate()` (or `x.iter{_mut}()` as appropriate). Also, the span of the suggestion has been corrected.
Fixes#4678
This lint will complain when you put a mutable function/method call
inside a `debug_assert` macro, because it will not be executed in
release mode, therefore it will change the execution flow, which is not
wanted.
Add `inefficient_to_string` lint
Closes#4586
changelog: Add `inefficient_to_string` lint, which checks for calling `to_string` on `&&str`, which would bypass the `str`'s specialization
`must_use_unit` lints unit-returning functions with a `#[must_use]`
attribute, suggesting to remove it.
`double_must_use` lints functions with a plain `#[must_use]`
attribute, but which return a type which is already `#[must_use]`,
so the attribute has no benefit.
`must_use_candidate` is a pedantic lint that lints functions and
methods that return some non-unit type that is not already
`#[must_use]` and suggests to add the annotation.
Lints when, on the RHS of a BinOp, there is a UnOp without a space
before the operator but with a space after (e.g. foo >- 1).
Signed-off-by: Nikos Filippakis <nikolaos.filippakis@cern.ch>
Add assert message to suggestion in lint assertions_on_constants
<!--
Thank you for making Clippy better!
We're collecting our changelog from pull request descriptions.
If your PR only updates to the latest nightly, you can leave the
`changelog` entry as `none`. Otherwise, please write a short comment
explaining your change.
If your PR fixes an issue, you can add "fixes #issue_number" into this
PR description. This way the issue will be automatically closed when
your PR is merged.
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.
- [x] Followed [lint naming conventions][lint_naming]
- [x] Added passing UI tests (including committed `.stderr` file)
- [ ] `cargo test` passes locally
- [x] Executed `./util/dev update_lints`
- [ ] Added lint documentation
- [ ] Run `./util/dev fmt`
[lint_naming]: https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints
Note that you can skip the above if you are just opening a WIP PR in
order to get feedback.
Delete this line and everything above before opening your PR -->
- [x] suggest replacing `assert!(false, "msg")` with `panic!("msg")`
- [x] extend to allow ~~variables~~ any expression for `"msg"`
- ~~suggest replacing `assert!(false, "msg {}", "arg")` with `panic!("msg {}", "arg")`~~
changelog: add assert message to suggestion in lint assertions_on_constants
Work towards fixing: #3575
Fix typo in inherent_to_string documentation
A simple typo fix in `inherent_to_string` and `inherent_to_string_shadow_display` documentation
changelog: none
account for doc visibility
This fixes#4608.
Also I noticed that the lint failed to look at trait and impl items. There's a small bit of fallout in the code, too, but not enough to warrant its own commit.
changelog: check docs of trait items and impl items, also make `missing_safety_doc` account for visibility
Add check for assert_eq macros to unit_cmp lint
changelog: Add check for unit comparisons through `assert_eq!`, `debug_assert_eq!`, `assert_ne!` and `debug_assert_ne!` macros to unit_cmp lint.
fixes#4481
Rollup of 2 pull requests
Successful merges:
- #4509 (Fix false-positive of redundant_clone and move to clippy::perf)
- #4614 (Allow casts from the result of `abs` to unsigned)
Failed merges:
changelog: none
r? @ghost
Fix false positive in `multiple_inherent_impl`
changelog: Fix false positive in `multiple_inherent_impl` by ignoring impls derived from macros.
Closes#4578.
Add a new lint for comparison chains
changelog: Adds a new lint: `comparison_chain`.
`comparison_chain` lints all `if` conditional chains where all the conditions are binary comparisons on the same two operands and will suggest a rewrite with `match`.
Closes#4531.
When license property is missing in Cargo.toml check for license-file
as it may be used instead of the former. The check implemented here is
very naive as it only verifies that the field is present and is not
empty. More scrutiny can be applied by verifying the file is actually
present.
Fixes#4517
#4542 remove machine applicable suggestion
This helps #4542 (but does not completely resolve) by removing the machine applicable suggestion (which was incorrect) for that case.
I would have preferred to fix the machine applicable suggestion to handle format strings, but that's a bit beyond my current understanding of the clippy codebase. I'd be happy to give it a try given some guidance.
changelog: only produce machine applicable suggestions on `explicit_write` lint
Changes cast-lossless to a pedantic lint
As discussed in #4528, this moves the cast-lossless lint from `all` to `pedantic`.
I couldn't tell from description alone if it should also be removed from the complexity category, so I left it as part of complexity for now. I didn't see any impact to the tests from this change, but I could be wrong (as this is my first PR).
fixes#4528
changelog: Moves cast-lossless from default to checking only as a `pedantic` lint.
Fix incorrect swap suggestion
Clippy suggests using swap on fields belonging to the same owner causing two mutable borrows of the owner.
Disclosure: This is my first time working with clippy and rusts HIR. I'm very grateful for assistance and suggestions to improve the PR.
fixes#981
changelog: Fix false positive in `manual_swap` lint
New `is_integer_const` to check more const ints
This mostly affects loop checks and the modulo_one lint. Tests were also updated where applicable.
changelog: none
Changed more `Vec` paths to diagnostic_items
In #4519, I missed a few instances of path matching for `Vec`, so here they are.
r? @oli-obk
changelog: none
Allow block_in_if_{stmt,expr} in external macro
I found this by running `cargo fix --clippy` on quite a big codebase.
You could refactor this assert to
```rust
let block_expr = _;
assert!(block_expr);
```
but,
1. it doesn't increase the readability IMO
2. That isn't possible in a `debug_assert!`
I'm not sure though, if we should allow this for macros in general or just for external macros.
changelog: Allow `block_in_if_{stmt,expr}` in external macros
Simplify `utils::match_def_path`, removing a FIXME
changelog: none
This removes the `Vec<Symbol>` allocation. We still need to call `cx.get_def_path`, but this should already have been interned, and I don't see how we can keep ergonomics of that function without allocating a `Vec`.
r? @phansch
fix misleading doc for explicit_counter_loop lint
changelog: replace misleading examples for explicit_counter_loop & more concise `Why is it bad?` section
This fixes#4472
Clippy suggests using swap on fields belonging to the same owner
causing two mutable borrows of the owner
Fixes#981
Signed-off-by: Cristian Kubis <cristian.kubis@tsunix.de>
Fix missing_const_for_fn false positive
We don't want to lint if the type of the method implements drop.
(constant functions cannot evaluate destructors)
changelog: Fix `missing_const_for_fn` false positive
Fixes#4449
More rustfix tests
<!--
Thank you for making Clippy better!
We're collecting our changelog from pull request descriptions.
If your PR only updates to the latest nightly, you can leave the
`changelog` entry as `none`. Otherwise, please write a short comment
explaining your change.
If your PR fixes an issue, you can add "fixes #issue_number" into this
PR description. This way the issue will be automatically closed when
your PR is merged.
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.
- [ ] Followed [lint naming conventions][lint_naming]
- [ ] Added passing UI tests (including committed `.stderr` file)
- [ ] `cargo test` passes locally
- [ ] Executed `./util/dev update_lints`
- [ ] Added lint documentation
- [ ] Run `./util/dev fmt`
[lint_naming]: https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints
Note that you can skip the above if you are just opening a WIP PR in
order to get feedback.
Delete this line and everything above before opening your PR -->
cc #3630
This is probably easier reviewed per-commit.
changelog: none
Fix unused_unit false positive
changelog: Fix `unused_unit` false positive
For some reason the `expr` of `stmt.node` didn't contain the expansion information, but the `stmt.span` does.
Fixes#4076
Account for trait alias when looking for defid
I hit the crash on the `expect` call when running clippy on rustc libcore.
Hopefully this will fix it.
changelog: none
Fix some suggestions for redundant_pattern_matching
.. and change the Applicability to `MaybeIncorrect`.
Fixes the problem displayed in https://github.com/rust-lang/rust-clippy/issues/4344#issuecomment-519206388.
We now append `{}` to the suggestion so that the conditional has the
correct syntax again.
(If we were to _remove_ the `if` instead, it would trigger the
`unused_must_use` warning for `#[must_use]` types.)
changelog: Fix some suggestions for `redundant_pattern_matching`
Fixes the problem displayed in https://github.com/rust-lang/rust-clippy/issues/4344#issuecomment-519206388.
We now append `{}` to the suggestion so that the conditional has the
correct syntax again.
(If we were to _remove_ the `if` instead, it would trigger the
`unused_must_use` warning for `#[must_use]` types.
Add autofixable suggestion for unseparated integer literal suffixes
changelog: Add autofixable suggestion for unseparated integer literal suffixes
Somewhat WIP, since I haven't been able to get this working when adding `// run-rustfix` to `ui/literals.rs`. I think the issue is that there are multiple suggestions operating on one numerical literal, and I'm not sure what the best approach is to work around that.
Thanks
Improvements to `type_repetition_in_bounds`
Improvements to the `type_repetition_in_bounds` trait based on feedback from #4380#4326#4323
Currently just make it pedantic. Hopefully, more to come
changelog: move `type_repetition_in_bounds` to `pedantic`
Add "could be written as" example to MANUAL_MEMCPY
<!--
Thank you for making Clippy better!
We're collecting our changelog from pull request descriptions.
If your PR only updates to the latest nightly, you can leave the
`changelog` entry as `none`. Otherwise, please write a short comment
explaining your change.
If your PR fixes an issue, you can add "fixes #issue_number" into this
PR description. This way the issue will be automatically closed when
your PR is merged.
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.
- [ ] Followed [lint naming conventions][lint_naming]
- [ ] Added passing UI tests (including committed `.stderr` file)
- [ ] `cargo test` passes locally
- [ ] Executed `./util/dev update_lints`
- [ ] Added lint documentation
- [ ] Run `./util/dev fmt`
[lint_naming]: https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints
Note that you can skip the above if you are just opening a WIP PR in
order to get feedback.
Delete this line and everything above before opening your PR -->
changelog: none
Update lint deprecation for tool lints
changelog: Allow tool lints (`clippy::*`) to be deprecated
Our lint deprecation previously didn't work for tool lints, because
`register_removed` was registering lints to be removed _without_ the
`clippy` prefix.
Fixes#4349
Our lint deprecation previously didn't work for tool lints, because
`register_removed` was registering lints to be removed _without_ the
`clippy` prefix.
new_ret_no_self: allow Self in inner type for impl Trait return types
Check the inner types of associated types of a trait when checking for Self in the return type of a `new` method. This means that the following will no longer warn:
```rust
trait Trait {
type Inner;
}
struct S;
impl S {
fn new() -> impl Trait<Inner = Option<Self>> {
struct TraitImpl;
impl Trait for TraitImpl {
type Inner = Option<S>;
}
TraitImpl
}
}
```
```rust
#![feature(async_await)]
struct Connection;
impl Connection {
async fn new() -> Result<Self, ()> {
Ok(S)
}
}
```
closes#4359
changelog: fix `new_ret_no_self` lint for async `new` functions.
Don't emit enum_variant_names if remainder starts with a numeric
changelog: Fix false positive in `pub_enum_variant_names` and `enum_variant_names`
As [per the reference](https://doc.rust-lang.org/reference/identifiers.html), identifiers must start with a letter. So we don't suggest a better
variant naming in case the remainder would start with a numeric.
Fixes#739
Add negation to `len_zero` lint to show more explicit message.
Fixes#4304 I have updated the `len_zero` to show the required negation in case of like the below case.
```
fn main() {
let v = vec![1];
if v.len() > 0 {
}
}
```
changelog: Clarify suggestion of `len_zero` lint.
Fix `for on` typo
<!--
Thank you for making Clippy better!
We're collecting our changelog from pull request descriptions.
If your PR only updates to the latest nightly, you can leave the
`changelog` entry as `none`. Otherwise, please write a short comment
explaining your change.
If your PR fixes an issue, you can add "fixes #issue_number" into this
PR description. This way the issue will be automatically closed when
your PR is merged.
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.
- [ ] Followed [lint naming conventions][lint_naming]
- [ ] Added passing UI tests (including committed `.stderr` file)
- [ ] `cargo test` passes locally
- [ ] Executed `util/dev update_lints`
- [ ] Added lint documentation
- [ ] Run `cargo fmt`
Note that you can skip the above if you are just opening a WIP PR in
order to get feedback.
Delete this line and everything above before opening your PR -->
closes#4317
changelog: minor typo fix
Mark `fn_to_numeric_cast` lints as MaybeIncorrect
At least for now so that `cargo fix --clippy` is not causing problems
with this lint. See #3896 for the remaining problems with the suggestions of this lint.
changelog: none
cc #3630, #3896
trait bounds lint - repeated types
This PR is to tackle https://github.com/rust-lang/rust-clippy/issues/3764 it's still a WIP and doesn't work but this is an initial stab. It builds though I haven't added any tests as I'm not sure where lint tests should go?
Unfortunately, it seems id isn't tied to the type itself but I guess where it is in the AST? Looking at https://manishearth.github.io/rust-internals-docs/syntax/ast/struct.Ty.html I can't see any members that would let me tell if a type was repeated in multiple trait bounds.
There may be other issues with how I've implemented this so any assistance is appreciated!
changelog: Add new lint: `type_repetition_in_bounds`
This lint adds warning if types are redundantly repeated in trait bounds i.e. `T: Copy, T: Clone` instead of `T: Copy + Clone`. This is a late pass trait lint and has necessitated the addition of code to allow hashing of TyKinds without taking into account Span information.
Ignore generated fresh lifetimes in elision check
<!--
Thank you for making Clippy better!
We're collecting our changelog from pull request descriptions.
If your PR only updates to the latest nightly, you can leave the
`changelog` entry as `none`. Otherwise, please write a short comment
explaining your change.
If your PR fixes an issue, you can add "fixes #issue_number" into this
PR description. This way the issue will be automatically closed when
your PR is merged.
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.
- [ ] Followed [lint naming conventions][lint_naming]
- [ ] Added passing UI tests (including committed `.stderr` file)
- [ ] `cargo test` passes locally
- [ ] Executed `util/dev update_lints`
- [ ] Added lint documentation
- [ ] Run `cargo fmt`
Note that you can skip the above if you are just opening a WIP PR in
order to get feedback.
Delete this line and everything above before opening your PR -->
fixes#3988
changelog: Ignore generated fresh lifetimes in elision check.
**HELP**: It seems `tests/ui` are compiled under edition 2015, and I don't know how to add tests for this properly.
Here is the test input it had already passed:
```rust
#![feature(async_await)]
#![allow(dead_code)]
async fn sink1<'a>(_: &'a str) {} // lint
async fn sink1_elided(_: &str) {} // ok
async fn one_to_one<'a>(s: &'a str) -> &'a str { s } // lint
async fn one_to_one_elided(s: &str) -> &str { s } // ok
async fn all_to_one<'a>(a: &'a str, _b: &'a str) -> &'a str { a } // ok
// async fn unrelated(_: &str, _: &str) {} // Not allowed in async fn
// #3988
struct Foo;
impl Foo {
pub async fn foo(&mut self) {} // ok
}
// rust-lang/rust#61115
async fn print(s: &str) { // ok
println!("{}", s);
}
fn main() {}
```
false positives fixes of `implicit_return`
- Handle returning macro statements properly (remove "this error originates in a macro outside of the current crate")
- Handle functions that return never type
- Handle functions that panic but do not return never type
changelog: Fix false positives in `implicit_return` lint pertaining to macros and panics
Fix bug in `implicit_hasher` causing crashes
Skip linting if the type is from an external macro. Closes#4260.
changelog: Fix bug in `implicit_hasher` causing crashes
Improve cast_ptr_alignment lint
<!--
Thank you for making Clippy better!
We're collecting our changelog from pull request descriptions.
If your PR only updates to the latest nightly, you can leave the
`changelog` entry as `none`. Otherwise, please write a short comment
explaining your change.
If your PR fixes an issue, you can add "fixes #issue_number" into this
PR description. This way the issue will be automatically closed when
your PR is merged.
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.
- [x] Followed [lint naming conventions][lint_naming]
- [x] Added passing UI tests (including committed `.stderr` file)
- [x] `cargo test` passes locally
- [x] Executed `util/dev update_lints`
- [x] Added lint documentation
- [x] Run `cargo fmt`
Note that you can skip the above if you are just opening a WIP PR in
order to get feedback.
Delete this line and everything above before opening your PR -->
* print alignment in bytes in the lint message
* ignore ZST left-hand types
Fixes#3797 and #4256
changelog:
* `cast_ptr_alignment`: Print alignment in bytes in the lint message
* `cast_ptr_alignment`: Ignore casting from ZST left-hand types
Avoid reporting string_lit_as_bytes for long strings
Port of @jens1o code ([b76f939][jens1o_commit])
Fixes#1208
[jens1o_commit]: b76f939ac2
<!--
Thank you for making Clippy better!
We're collecting our changelog from pull request descriptions.
If your PR only updates to the latest nightly, you can leave the
`changelog` entry as `none`. Otherwise, please write a short comment
explaining your change.
If your PR fixes an issue, you can add "fixes #issue_number" into this
PR description. This way the issue will be automatically closed when
your PR is merged.
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.
- [ ] Followed [lint naming conventions][lint_naming]
- [ ] Added passing UI tests (including committed `.stderr` file)
- [ ] `cargo test` passes locally
- [ ] Executed `util/dev update_lints`
- [ ] Added lint documentation
- [ ] Run `cargo fmt`
Note that you can skip the above if you are just opening a WIP PR in
order to get feedback.
Delete this line and everything above before opening your PR -->
changelog: bugfix for long strings as bytes
make needless_return work with void functions
fixes https://github.com/rust-lang/rust-clippy/issues/4181.
changelog: make needless_return work with void functions.
I don't think the failure is related to my changes, but I'm not sure 🤔
Downgrade integer_division to restriction
I believe that this lint falls outside of the scope of opinionated pedantism of the other pedantic lints.
changelog: Downgrade integer_division lint from pedantic to restriction
lint does not trigger when there is a difference in mutability
lint does not trigger when the method belongs to a trait which is not implemebted directly (Deref)
Fixing eta with respect to lazy evaluation.
This fixes#4187
changelog: `redundant_closure`: stop linting on expressions returning a function, which is then directly used by the closure
Add example to needless_range_loop
adds a "could be written as" example
btw, is it correct that the lint triggers even if the index is used not just for getting the values by index?
So that I have to add `.iter().enumerate()` to still get an index?
changelog: none
trivially_copy_pass_by_ref: print size of type and limit in the lint message
changelog: trivially_copy_pass_by_ref: print size of type and limit in the lint message
Fix match_same_arms to fail late
Changes:
- Add a function search_same_list which return a list of matched expressions
- Change the match_same_arms implementation behavior. It will lint each same arms found.
fixes#4096
changelog: none
Implement "Use last" lint
Closes#3673
This lint checks the use of `x.get(x.len() - 1)` and suggests `x.last()` (where `x` is a `Vec`).
There's at least one more thing that needs to happen here. I believe I am correctly checking most of the scenarios and avoiding false positives. However, if different `Vec`s are used for the `x.get` and `y.len`, then it will emit a false positive. In other words, I need to check to make sure the `Vec`s are the same.
Also, a lot of these commits were temporary and not helpful to the project history...am I supposed to squash on merge? If so, how do I do that?
changelog: New lint: `get_last_with_len`
Added lint for TryFrom for checked integer conversion.
works towards #3947
Added lint for try_from for checked integer conversion.
Should recognize simple & straight-forward checked integer conversions.
Changes:
- Add a function search_same_list which return a list of matched expressions
- Change the match_same_arms implementation behaviour. It will lint each same arms found.
Move the method checking into a new lint called
`redundant_closures_for_method_calls` and put it in the pedantic group.
This aspect of the lint seems more controversial than the rest.
cc #3942
Fix#4033 search_is_some
Fixes#4033.
Suggest `any(|x| ..)` instead of `any(|&x| ..)` for `find(|&x| ..).is_some()` (Lint [search_is_some](https://rust-lang.github.io/rust-clippy/master/index.html#search_is_some))
FnDecl of `find`:
```rust
fn find<P>(&mut self, mut p: P) -> Option<Self::Item> where
P: FnMut(&Self::Item) -> bool
```
FnDecl of `any`:
```rust
fn any<F>(&mut self, mut f: F) -> bool where
F: FnMut(Self::Item) -> bool
```
If match on `|&_|` in closure of `find`, only use `|_|` in the suggestion.
PS. It's the first time that I have used the `hir` API, please correct me if there is any mistake 😺
useless_let_if_seq handle interior mutability
fixes#3043
This passes all tests, including a new one specifically dealing with a type with interior mutability. The main thing I'm unsure of is whether the span I used in the call to `is_freeze` is the most appropriate span to use, or if it matters.
Do not trigger redundant_closure for non-function types
fixes#3898
Added a check for the entity being called in the closure body to be a FnDef. This way lint does not trigger for ADTs (Box) but I'm not sure if it's correct and not too restrictive.
<!--
Thank you for making Clippy better!
We're collecting our changelog from pull request descriptions.
If your PR only updates to the latest nightly, you can leave the
`changelog` entry as `none`. Otherwise, please write a short comment
explaining your change.
If your PR fixes an issue, you can add "fixes #issue_number" into this
PR description. This way the issue will be automatically closed when
your PR is merged.
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.
- [ ] Followed [lint naming conventions][lint_naming]
- [ ] Added passing UI tests (including committed `.stderr` file)
- [ ] `cargo test` passes locally
- [ ] Executed `util/dev update_lints`
- [ ] Added lint documentation
- [ ] Run `cargo fmt`
Note that you can skip the above if you are just opening a WIP PR in
order to get feedback.
Delete this line and everything above before opening your PR -->
changelog: Fix false positive in `redundant_closure` pertaining to non-function types
Ignore non-const ctor expressions in or_fn_call
Fixes https://github.com/rust-lang/rust-clippy/issues/1338
Should have been fixed by #919, however that focuses on const ctor expressions only, and `.or(Some(local))` isn't const.
This also automatically ignores things like `.or(Some(local.clone())` which we don't actually want to do; I need to figure out what to do here.
changelog: Fixed false positive in [`or_fn_call`] pertaining to enum variant constructors
r? @oli-obk @phansch
Allow allowing of toplevel_ref_arg lint
I'm not sure why some lints need the `HirId` to be able to recognize the
lint level attributes, but this commit makes the lint level attributes
work for `toplevel_ref_arg`.
Fixes#2332
changelog: Allow allowing of `toplevel_ref_arg` lint
Fix false positive in module_name_repetitions lint
This lint was triggering on modules inside expanded attrs, like
for example `#[cfg(test)]` and possibly more.
It was not reporting a location in #3892 because `span.lo()` and `span.hi()` both were 0.
Fixes#3892
changelog: Fix false positive in `module_name_repetitions` lint
I'm not sure why some lints need the `HirId` to be able to recognize the
lint level attributes, but this commit makes the lint level attributes
work for `toplevel_ref_arg`.
Change naive_bytecount applicability to MaybeIncorrect
We can't use `MachineApplicable` here as applying the fix will cause
another error because `bytecount` would first have to be added to the
Cargo.toml.
Example:
```
error: You appear to be counting bytes the naive way
--> $DIR/bytecount.rs:5:13
|
LL | let _ = x.iter().filter(|&&a| a == 0).count(); // naive byte count
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: Consider using the bytecount crate: `bytecount::count(x, 0)`
```
Just replacing it with the suggestion is not enough.
cc #3630
Change while_let_loop applicability to HasPlaceholders
The suggestion has been changed at some point to use `..` in the suggested code.
Due to that we can't make the lint MachineApplicable anymore.
cc #3630
This was causing two different ICEs in #3741.
The first was fixed in #3925.
The second one is fixed with this commit: We just don't `expect`
anymore. If the snippet doesn't contain an `else`, we stop emitting the
lint because it's not a suspiciously formatted else anyway.
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
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.
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
Refactor: Cleanup one part of assign_ops lint
Removes a lot of indentation and separates lint emission from lint
logic. Only touches the `hir::ExprKind::AssignOp` part of the lint.
Refactor: Extract `trait_ref_of_method` function
This pattern was used in three places after #3844, so I think it's worth moving it into `utils/mod.rs` and documenting it.
* 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
Extract diagnostics module and document some functions
This moves the lint building functions from `utils/mod.rs` to their own
`utils/diagnostics.rs` file. Also adds documentation for three of them.
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 :)
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)
Pass tests for #3778, {print,write}_with_newline false positive
This change guards the lint from checking newlines with a sort of complicated
check to see if it's a raw string. Raw strings shouldn't be newline-checked,
since r"\n" is literally \-n, not a newline. I think it's ok not to check for
_literal_ newlines at the end of raw strings, but maybe that's debatable.
I... don't think this code is that great. I wanted to write the check after
`check_tts`, but that was too late -- raw string type info is lost (or I
couldn't find it). Putting it inside `check_tts` feels heavy-duty and the check
itself feels like a brittle reach possibly into places it shouldn't.
Maybe someone can fix this up :)
**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>() {}
```
