issue #8239: Printed hint for lint or_fun_call is cropped and does no…
fixesrust-lang/rust-clippy#8239
changelog: [`or_fun_call`]: if suggestion contains more lines than MAX_SUGGESTION_HIGHLIGHT_LINES it is stripped to one line
* Track the argument when used to initialize simple `let` bindings
* Check if the argument is passed to a function requiring the original type
* Use `multipart_suggestion` rather than multiple suggestions
* Check if the name given in the source code matches the name of the actual type
`manual_memcpy` fix
fixes#8160
Ideally this would work with `VecDeque`, but the current interface is unsuitable for it. At a minimum something like `range_as_slices` would be needed.
changelog: Don't lint `manual_memcpy` on `VecDeque`
changelog: Suggest `copy_from_slice` for `manual_memcpy` when applicable
This pull request adds a lint against single character lifetime names, as they might not divulge enough information about the purpose of the lifetime. This can make code harder to understand. I placed this in `restriction` rather than `pedantic` (as suggested in #8233) since most of the Rust ecosystem already uses single character lifetime names (to my knowledge, at least) and since single character lifetime names aren't incorrect. I'd be happy to change this upon request, however. Fixes#8233.
- [x] Followed lint naming conventions
- [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`
changelog: new lint: [`single_char_lifetime_names`]
Better detect when a field can be moved from in `while_let_on_iterator`
fixes#8113
changelog: Better detect when a field can be moved from in `while_let_on_iterator`
Fix `type_repetition_in_bounds`
fixes#7360fixes#8162fixes#8056
changelog: Check for full equality in `type_repetition_in_bounds` rather than just equal hashes
New macro utils
changelog: none
Sorry, this is a big one. A lot of interrelated changes and I wanted to put the new utils to use to make sure they are somewhat battle-tested. We may want to divide some of the lint-specific refactoring commits into batches for smaller reviewing tasks. I could also split into more PRs.
Introduces a bunch of new utils at `clippy_utils::macros::...`. Please read through the docs and give any feedback! I'm happy to introduce `MacroCall` and various functions to retrieve an instance. It feels like the missing puzzle piece. I'm also introducing `ExpnId` from rustc as "useful for Clippy too". `@rust-lang/clippy`
Fixes#7843 by not parsing every node of macro implementations, at least the major offenders.
I probably want to get rid of `is_expn_of` at some point.
changelog: none
Sorry, this is a big one. A lot of interrelated changes and I wanted to put the new utils to use to make sure they are somewhat battle-tested. We may want to divide some of the lint-specific refactoring commits into batches for smaller reviewing tasks. I could also split into more PRs.
Introduces a bunch of new utils at `clippy_utils::macros::...`. Please read through the docs and give any feedback! I'm happy to introduce `MacroCall` and various functions to retrieve an instance. It feels like the missing puzzle piece. I'm also introducing `ExpnId` from rustc as "useful for Clippy too". `@rust-lang/clippy`
Fixes#7843 by not parsing every node of macro implementations, at least the major offenders.
I probably want to get rid of `is_expn_of` at some point.
wrong_self_convention: Match `SelfKind::No` more restrictively
The `wrong_self_convention` lint uses a `SelfKind` type to decide
whether a method has the right kind of "self" for its name, or whether
the kind of "self" it has makes its name confusable for a method in
a common trait. One possibility is `SelfKind::No`, which is supposed
to mean "No `self`".
Previously, SelfKind::No matched everything _except_ Self, including
references to Self. This patch changes it to match Self, &Self, &mut
Self, Box<Self>, and so on.
For example, this kind of method was allowed before:
```
impl S {
// Should trigger the lint, because
// "methods called `is_*` usually take `self` by reference or no `self`"
fn is_foo(&mut self) -> bool { todo!() }
}
```
But since SelfKind::No matched "&mut self", no lint was triggered
(see #8142).
With this patch, the code above now gives a lint as expected.
fixes#8142
changelog: [`wrong_self_convention`] rejects `self` references in more cases
Inspired by a discussion in rust-lang/rust-clippy#8197
---
r? `@llogiq`
changelog: none
The lint is this on nightly, therefore no changelog entry for you xD
The `wrong_self_convention` lint uses a `SelfKind` type to decide
whether a method has the right kind of "self" for its name, or whether
the kind of "self" it has makes its name confusable for a method in
a common trait. One possibility is `SelfKind::No`, which is supposed
to mean "No `self`".
Previously, SelfKind::No matched everything _except_ Self, including
references to Self. This patch changes it to match Self, &Self, &mut
Self, Box<Self>, and so on.
For example, this kind of method was allowed before:
```
impl S {
// Should trigger the lint, because
// "methods called `is_*` usually take `self` by reference or no `self`"
fn is_foo(&mut self) -> bool { todo!() }
}
```
But since SelfKind::No matched "&mut self", no lint was triggered
(see #8142).
With this patch, the code above now gives a lint as expected.
Fixes#8142
changelog: [`wrong_self_convention`] rejects `self` references in more cases
This improves the quality of the genrated output and makes it
more in line with other lint messages.
changelog: [`unused_io_amount`]: Improve help text
Clippy helpfully warns about code like this, telling you that you
probably meant "write_all":
fn say_hi<W:Write>(w: &mut W) {
w.write(b"hello").unwrap();
}
This patch attempts to extend the lint so it also covers this
case:
async fn say_hi<W:AsyncWrite>(w: &mut W) {
w.write(b"hello").await.unwrap();
}
(I've run into this second case several times in my own programming,
and so have my coworkers, so unless we're especially accident-prone
in this area, it's probably worth addressing?)
This patch covers the Async{Read,Write}Ext traits in futures-rs,
and in tokio, since both are quite widely used.
changelog: [`unused_io_amount`] now supports AsyncReadExt and AsyncWriteExt.
Limit the ``[`identity_op`]`` lint to integral operands.
changelog: limit ``[`identity_op`]`` to integral operands
In the ``[`identity_op`]`` lint, if the operands are non-integers, then the lint is likely
wrong.
Fixed issues with to_radians and to_degrees lints
fixes#7651
I fixed the original problem as described in the issue, but the bug remains for complex expressions (the commented out TC I added is an example). I would also love some feedback on how to cleanup my code and reduce duplication. I hope it's not a problem that the issue has been claimed by someone else - that was over two months ago.
changelog: ``[`suboptimal_flops`]`` no longer proposes broken code with `to_radians` and `to_degrees`
Fix `enum_variants` FP on prefixes that are not camel-case
closes#8090
Fix FP on `enum_variants` when prefixes are only a substring of a camel-case word. Also adds some util helpers on `str_utils` to help parsing camel-case strings.
This changes how the lint behaves:
1. previously if the Prefix is only a length of 1, it's going to get ignored, i.e. these were previously ignored and now is warned
```rust
enum Foo {
cFoo,
cBar,
cBaz,
}
enum Something {
CCall,
CCreate,
CCryogenize,
}
```
2. non-ascii characters that doesn't have casing will not be split,
```rust
enum NonCaps {
PrefixXXX,
PrefixTea,
PrefixCake,
}
```
will be considered as `PrefixXXX`, `Prefix`, `Prefix`, so this won't lint as opposed to fired previously.
changelog: [`enum_variant_names`] Fix FP when first prefix are only a substring of a camel-case word.
---
(Edited by `@xFrednet` removed some non ascii characters)
closes#8177
previously, `needless_return` suggests an empty block `{}` to replace void `return` on match arms, this PR improve the suggestion by suggesting a unit instead.
changelog: `needless_return` suggests `()` instead of `{}` on match arms
Fix `SAFETY` comment tag casing in undocumented_unsafe_blocks
This changes the lint introduced in #7748 to suggest adding a `SAFETY` comment instead of a `Safety` comment.
Searching for `// Safety:` in rust-lang/rust yields 67 results while `// SAFETY:` yields 1072.
I think it's safe to say that this comment tag is written in upper case, just like `TODO`, `FIXME` and so on are. As such I would expect this lint to follow the official convention as well.
Note that I intentionally introduced some casing diversity in `tests/ui/undocumented_unsafe_blocks.rs` to test more cases than just `Safety:`.
changelog: Capitalize `SAFETY` comment in [`undocumented_unsafe_blocks`]
Don't emit RETURN_SELF_NOT_MUST_USE lint if `Self` already is marked as `#[must_use]`
New bug discovered with this lint. Hopefully, this is the last one.
---
changelog: none
Ensure that RETURN_SELF_NOT_MUST_USE is not emitted if the method already has `#[must_use]`
Fixes https://github.com/rust-lang/rust-clippy/issues/8140.
---
Edit:
changelog: none
(The lint is not in beta yet, this should therefore not be included inside the changelog :) )
Implement let-else type annotations natively
Tracking issue: #87335Fixes#89688, fixes#89807, edit: fixes #89960 as well
As explained in https://github.com/rust-lang/rust/issues/89688#issuecomment-940405082, the previous desugaring moved the let-else scrutinee into a dummy variable, which meant if you wanted to refer to it again in the else block, it had moved.
This introduces a new hir type, ~~`hir::LetExpr`~~ `hir::Let`, which takes over all the fields of `hir::ExprKind::Let(...)` and adds an optional type annotation. The `hir::Let` is then treated like a `hir::Local` when type checking a function body, specifically:
* `GatherLocalsVisitor` overrides a new `Visitor::visit_let_expr` and does pretty much exactly what it does for `visit_local`, assigning a local type to the `hir::Let` ~~(they could be deduplicated but they are right next to each other, so at least we know they're the same)~~
* It reuses the code in `check_decl_local` to typecheck the `hir::Let`, simply returning 'bool' for the expression type after doing that.
* ~~`FnCtxt::check_expr_let` passes this local type in to `demand_scrutinee_type`, and then imitates check_decl_local's pattern checking~~
* ~~`demand_scrutinee_type` (the blindest change for me, please give this extra scrutiny) uses this local type instead of of creating a new one~~
* ~~Just realised the `check_expr_with_needs` was passing NoExpectation further down, need to pass the type there too. And apparently this Expectation API already exists.~~
Some other misc notes:
* ~~Is the clippy code supposed to be autoformatted? I tried not to give huge diffs but maybe some rustfmt changes simply haven't hit it yet.~~
* in `rustc_ast_lowering/src/block.rs`, I noticed some existing `self.alias_attrs()` calls in `LoweringContext::lower_stmts` seem to be copying attributes from the lowered locals/etc to the statements. Is that right? I'm new at this, I don't know.
Tweak errors coming from `for`-loop, `?` and `.await` desugaring
* Suggest removal of `.await` on non-`Future` expression
* Keep track of obligations introduced by desugaring
* Remove span pointing at method for obligation errors coming from desugaring
* Point at called local sync `fn` and suggest making it `async`
```
error[E0277]: `()` is not a future
--> $DIR/unnecessary-await.rs:9:10
|
LL | boo().await;
| -----^^^^^^ `()` is not a future
| |
| this call returns `()`
|
= help: the trait `Future` is not implemented for `()`
help: do not `.await` the expression
|
LL - boo().await;
LL + boo();
|
help: alternatively, consider making `fn boo` asynchronous
|
LL | async fn boo () {}
| +++++
```
Fix#66731.
Stabilize asm! and global_asm!
Tracking issue: #72016
It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature!
The main changes in this PR are:
- Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228.
- Stabilizing the `asm` and `global_asm` features.
- Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483).
- All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example.
- Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax, since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`.
- Updating `stdarch` and `compiler-builtins`.
- Updating all the tests.
r? `@joshtriplett`
fix clippy format using `cargo fmt -p clippy_{lints,utils}`
manually revert rustfmt line truncations
rename to hir::Let in clippy
Undo the shadowing of various `expr` variables after renaming `scrutinee`
reduce destructuring of hir::Let to avoid `expr` collisions
cargo fmt -p clippy_{lints,utils}
bless new clippy::author output
Add new lint to warn when #[must_use] attribute should be used on a method
This lint is somewhat similar to https://rust-lang.github.io/rust-clippy/master/index.html#must_use_candidate but also different: it emits a warning by default and only targets methods (so not functions nor associated functions).
Someone suggested it to me after this tweet: https://twitter.com/m_ou_se/status/1466439813230477312
I think it would reduce the number of cases of API misuses quite a lot.
What do you think?
---
changelog: Added new [`return_self_not_must_use`] lint
Ignore associated types in traits when considering type complexity
changelog: Ignore associated types in traits when checking ``[`type_complexity`]`` lint.
fixes#1013
Fix bad suggestion on `option_if_let_else` when there is complex subpat
closes#7991
Prefer not warning any complex subpat in `option_if_let_else` rather than suggesting obscure suggestions.
changelog: [`option_if_let_else`] does not warn when complex subpat is present
Parenthesize blocks in `needless_bool` suggestion
Because the `if .. {}` statement already puts the condition in expression scope, contained blocks would be parsed as complete
statements, so any `&` binary expression whose left operand ended in a block would lead to a non-compiling suggestion.
We identify such expressions and add parentheses. Note that we don't make a difference between normal and unsafe blocks because the parsing problems are the same for both.
This fixes#8052.
---
changelog: none
Because the `if .. {}` statement already puts the condition in
expression scope, contained blocks would be parsed as complete
statements, so any `&` binary expression whose left operand ended in a
block would lead to a non-compiling suggestion.
This adds a visitor to identify such expressions and add parentheses.
This fixes#8052.
Consider NonNull as a pointer type
PR 1/2 for issue #8045. Add `NonNull` as a pointer class to suppress false positives like `UnsafeCell<NonNull<()>>`. However, this change is not sufficient to handle the cases shared in gtk-rs and Rug in the issue.
changelog: none
r? `@xFrednet`
Fix `any()` not taking reference in `search_is_some` lint
`find` gives reference to the item, but `any` does not, so suggestion is broken in some specific cases.
Fixes: #7392
changelog: [`search_is_some`] Fix suggestion for `any()` not taking item by reference
Add test for pattern_type_mismatch.
This issue has been fixed by [commit](8c1c763c2d)
This PR is used for close #7946(Fixes#7946).
changelog: Add test for pattern_type_mismatch.
Improve `strlen_on_c_string`
fixes: #7436
changelog: lint `strlen_on_c_string` when used without a fully-qualified path
changelog: suggest removing the surrounding unsafe block for `strlen_on_c_string` when possible
Prior to PR #91205, checking for errors in the overall obligation
would check checking the `ParamEnv`, due to an incorrect
`super_visit_with` impl. With this bug fixed, we will now
bail out of impl candidate assembly if the `ParamEnv` contains
any error types.
In practice, this appears to be overly conservative - when an error
occurs early in compilation, we end up giving up early for some
predicates that we could have successfully evaluated without overflow.
By only checking for errors in the predicate itself, we avoid causing
additional spurious 'type annotations needed' errors after a 'real'
error has already occurred.
With this PR, the diagnostic changes caused by PR #91205 are reverted.
Add `needless_late_init` lint
examples:
```rust
let a;
a = 1;
// to
let a = 1;
```
```rust
let b;
match 3 {
0 => b = "zero",
1 => b = "one",
_ => b = "many",
}
// to
let b = match 3 {
0 => "zero",
1 => "one",
_ => "many",
};
```
```rust
let c;
if true {
c = 1;
} else {
c = -1;
}
// to
let c = if true {
1
} else {
-1
};
```
changelog: Add [`needless_late_init`]
Visit `param_env` field in Obligation's `TypeFoldable` impl
This oversight appears to have gone unnoticed for a long time
without causing issues, but it should still be fixed.
Add new lint `octal_escapes`
This checks for sequences in strings that would be octal character
escapes in C, but are not supported in Rust. It suggests either
to use the `\x00` escape, or an equivalent hex escape if the octal
was intended.
Fixes#7981
---
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: Add new lint [`octal_escapes`], which checks for literals like `"\033[0m"`.
