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
