new lint: `manual_while_let_some`
This PR implements the lint I suggested [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/lint.20on.20while.20pop.20unwrap).
It looks for while loops like these:
```rs
let mut numbers = vec![0, 1, 2];
while !numbers.is_empty() {
let number = numbers.pop().unwrap();
// use `number`
}
```
and suggests replacing it with a while-let loop, like this:
```rs
let mut numbers = vec![0, 1, 2];
while let Some(number) = numbers.pop() {
// use `number`
}
```
... which is more concise and idiomatic.
It only looks for `Vec::pop()` calls in the first statement of the loop body in an attempt to not trigger FPs (as pop might only be called conditionally).
changelog: new lint [`manual_while_let_some`]
Fix `items_after_test_module`: Ignore imported modules
Fixes#10713. It does a little bit of dark magic, but intention is what really counts.
changelog:[`items_after_test_module`]: Ignore imported modules (`mod foo;`) with no body.
fix new lints link
install nightly rust-docs
run linkcheck without nightly toolchain
remove nightly toolchain, add rust-docs component
Test Remark
Update basics.md
Update basics.md
Update basics.md
update workflow
add rust docs toolchain
Update remark.yml
workflow test
manual test
update book path
add linkcheck book to CI
Update lint_passes.md
Using `default` to construct a unit struct increases code complexity and
adds a function call. This can be avoided by simply removing the call to
`default` and simply construct by name.
Add configuration for `semicolon_block` lints
Does exactly what it says on the tin, suggests moving a block's final semicolon inside if it's multiline and outside if it's singleline.
I don't really like how this is implemented so I'm not too sure if this is ready yet. Alas, it might be ok.
---
fixes#10654
changelog: Enhancement: [`semicolon_inside_block`]: Added `semicolon-inside-block-ignore-singleline` as a new config value.
[#10656](https://github.com/rust-lang/rust-clippy/pull/10656)
changelog: Enhancement: [`semicolon_outside_block`]: Added `semicolon-outside-block-ignore-multiline` as a new config value.
[#10656](https://github.com/rust-lang/rust-clippy/pull/10656)
<!-- changelog_checked -->
Switch to `EarlyBinder` for `explicit_item_bounds`
Part of the work to finish https://github.com/rust-lang/rust/issues/105779.
This PR adds `EarlyBinder` to the return type of the `explicit_item_bounds` query and removes `bound_explicit_item_bounds`.
r? `@compiler-errors` (hope it's okay to request you, since you reviewed #110299 and #110498😃)
Document that `cargo clippy --fix` implies `--all-targets`
In [`cargo fix`'s documentation](https://doc.rust-lang.org/cargo/commands/cargo-fix.html) they indicate that `fix` implies `--all-targets` if no target is supplied. As Clippy uses Cargo under the hood, this also applies to Clippy, but we didn't document that behaviour.
This PR changes that
Fixes#10690
changelog: Add to documentation that `--fix` implies `--all-targets`
Catching, stray, commas, (I'll, never, learn, to, use, them, correctly) 😅
Roses are red,
Violets are blue,
Fixing commas,
Is the completed todo.
(It's always impressive, that the poems are getting worse)
---
Follow-up from: https://github.com/rust-lang/rust-clippy/pull/10668
changelog: none
Don't apply `string_lit_as_bytes` if in macro expansion
The following code will emit a warning on both w! and h!, despite there being nothing the user (or library author) could do about it:
```rust
#![warn(clippy::string_lit_as_bytes)]
use windows::w;
use windows::h;
fn main() {
let _w = w!("example");
let _h = h!("example");
}
```
This is because windows-rs will create a binding `const INPUT: &[u8] = $s.as_bytes()`, and changing this to b"$s" is, well, suboptimal. I don't know enough about Rust to know if this is something that can be detected though if it can be I'm happy with closing this in favor of implementing that.
I'm not sure whether this is how it should be done though, as this simply tells clippy to not invoke this even if it's applicable (this also affects the other string lints, but didn't cause any tests to fail).
changelog: [`string_lit_as_bytes`]: Don't lint if in external macro
Improve the help message + add a help span
This would close#10410, because it applies the general consensus achieved in that issue (that replacing `let _ = ...` to `_ = ...` doesn't present any benefits).
I also added a little help message span.
changelog:[`let_underscore_untyped`]: Fix the help message confusion + add a help message span.
check for `..` pattern in `redundant_pattern_matching`
The `redundant_pattern_matching` lint currently checks for `if let Some(_) = ...`, but not for `if let Some(..) = ...`.
This PR makes sure to also check for the `..` pattern in tuple structs.
It also found one such instance in clippy itself so that shows it's worth checking for this pattern as well 😅
changelog: [`redundant_pattern_matching`]: check for `..` pattern in tuple structs
Fix false positive in `allow_attributes`
This would emit a warning if used in a proc-macro with the feature `lint_reasons` enabled. This is now fixed.
changelog: [`allow_attributes`]: Don't lint if in external macro
Ignore `shadow` warns in code from macro expansions
This PR fixes https://github.com/rust-lang/rust-clippy/issues/9757
I am in doubt if just looking for `pat.span.from_expansion()` would be sufficient instead of looking for both `pat.span.desugaring_kind().is_some()` or `pat.span.from_expansion()`. The tests (including the new one) passes if I leave the only `if pat.span.from_expansion()`. Any feedbacks?
Also, this is my first PR here, sorry for anything and thanks for the patience!
changelog: [`shadow_same`, `shadow_reuse`, `shadow_unrelated`]: avoiding warns in macro-generated code
