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 -->
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
New lint: detect `if` expressions with simple boolean assignments to the same target
Closes#10430
changelog: [`needless_bool_assign`] new lint to detect simple boolean assignment to the same target in `if` branches
use `is_inside_const_context` for `in_constant` util fn
Fixes#10452.
This PR improves the `in_constant` util function to detect more cases of const contexts. Previously this function would not detect cases like expressions in array length position or expression in an inline const block `const { .. }`.
changelog: [`bool_to_int_with_if`]: recognize array length operand as being in a const context and don't suggest `usize::from` there
Don't suggest `suboptimal_flops` unavailable in nostd
Fixes#10634
changelog: Enhancement: [`suboptimal_flops`]: Do not suggest `{f32,f64}::abs()` or `{f32,f64}::mul_add()` in a `no_std`-environment.
Add `items_after_test_module` lint
Resolves task *3* of #10506, alongside *1* resolved at #10543 in an effort to help standarize a little bit more testing modules.
---
changelog:[`items_after_test_module`]: Added the lint.
make [`len_zero`] lint not spanning over parenthesis
sorry it should be a quick fix but I was caught up by other stuffs last couple weeks 🤦♂️
---
fixes: #10529
changelog: make [`len_zero`] lint not spanning over parenthesis
Evaluate place expression in `PlaceMention`
https://github.com/rust-lang/rust/pull/102256 introduces a `PlaceMention(place)` MIR statement which keep trace of `let _ = place` statements from surface rust, but without semantics.
This PR proposes to change the behaviour of `let _ =` patterns with respect to the borrow-checker to verify that the bound place is live.
Specifically, consider this code:
```rust
let _ = {
let a = 5;
&a
};
```
This passes borrowck without error on stable. Meanwhile, replacing `_` by `_: _` or `_p` errors with "error[E0597]: `a` does not live long enough", [see playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c448d25a7c205dc95a0967fe96bccce8).
This PR *does not* change how `_` patterns behave with respect to initializedness: it remains ok to bind a moved-from place to `_`.
The relevant test is `tests/ui/borrowck/let_underscore_temporary.rs`. Crater check found no regression.
For consistency, this PR changes miri to evaluate the place found in `PlaceMention`, and report eventual dangling pointers found within it.
r? `@RalfJung`
