#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.
tests: disable incremental compilation in dogfood to reduce target dir size
tests: execute dogfood tests with incremental compilation disabled reduces target/ dir size of when "cargo test"ing by around 2 gigs.
changelog: none
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
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
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
Split up cmp_owned tests, add run-rustfix
Some of the cmp_owned tests emitted non-machine-applicable suggestions,
so I moved them to `tests/ui/cmp_owned/without_suggestion.rs` and added
`// run-rustfix` to the other half.
changelog: none
cc #3630
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
Some of the cmp_owned tests emitted non-machine-applicable suggestions,
so I moved them to `tests/ui/cmp_owned/without_suggestion.rs` and added
`// run-rustfix` to the other half.
cc #3630
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
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.
Add run-rustfix for needless_bool lint
This splits up the needless_bool tests into `fixable.rs` and
`simple.rs`. `simple.rs` contains the code that triggers the lint
diagnostic without a suggestion.
changelog: none
cc #3630
This splits up the needless_bool tests into `fixable.rs` and
`simple.rs`. `simple.rs` contains the code that triggers the lint
diagnostic without a suggestion.
Split up cast.rs tests, run-rustfix for unnecessary_cast
This splits up the cast.rs tests and enables rustfix tests for the part
of the `unnecessary_cast` lint that emits `MachineApplicable`
suggestions.
changelog: none
cc #3630
This splits up the cast.rs tests and enables rustfix tests for the part
of the `unnecessary_cast` lint that emits `MachineApplicable`
suggestions.
cc #3630
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.
UI Test Cleanup: No wrong_self_convention in methods.rs
These cases are already covered in `tests/ui/wrong_self_convention.rs`.
cc #2038
changelog: none
Don't nudge people towards toilet closures when producing owl results
`.map_err(drop)` should never be linted since sometimes you want to produce `Result<(), ()>` and the alternative is `.map_err(|_| ())`, which can be ugly. We don't seem to, but it's good to specifically test for this.
changelog: none
r? @yaahallo
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.
