This matches `cargo fmt` behavior but for `format!(...)` -style macro
calls.
To make this PR easier to review, it moves all linting of the clippy
code to rust-lang/rust-clippy#16533
Suggest removing an unnecessary trailing comma before the closing
parenthesis in single-line format-like macro invocations (e.g. println!,
format!, write!). The lint currently only runs on format-like macros
because it relies on format-argument parsing; arbitrary user macros are
not supported to avoid incorrect suggestions.
- Lint is in the `style` group (allow-by-default)
- Single-line only: multi-line macro invocations are not linted
- Machine-applicable fix: removes the trailing comma
```rust
// catches this
debug!("Foo={}", 1,);
// suggests this
debug!("Foo={}", 1);
```
Closesrust-lang/rust-clippy#13965
changelog: [`unnecessary_trailing_comma`]: new lint to remove trailing
commas in a single-line format macro usage
Based on rust-lang/rust-clippy#15947
Simple change in this one. Lints are parsed into a map indexed by name
in order to detect overlapping lint names. The panic message when a
duplicate name is parsed is unhelpful right now. That will be fixed in a
future PR along with improving all the other parsing errors.
changelog: none
Using `e.span.from_expansion()` alone prevented the lint from firing
within compiler-desugared expressions, e.g. `async fn`, `for` loops, or
`?`.
changelog: [`useless_conversion`]: also fire inside compiler desugarings
closerust-lang/rust-clippy#16590
This removes code duplication. Also, this limits the number of places to
update when rustc lint code interface is modified to two places.
changelog: none
rust-lang/rust-clippy#16535
This PR introduces a new configuration option, `allow-unwrap-types`,
which accepts a list of type paths (e.g., `["std::sync::LockResult"]`).
When configured, calling `.unwrap()` or `.expect()` on values of these
types will no longer trigger the `unwrap_used` or `expect_used` lints.
This is particularly useful for reducing noisy lints on patterns where
unwrapping is widely considered acceptable or expected by design, such
as obtaining a `std::sync::LockResult` from `Mutex::lock()`.
**Changes Made**
Introduced the `allow_unwrap_types: Vec<String>` field in
`clippy_config`.
Updated the `unwrap_expect_used` lint to check the underlying evaluated
expression `ty` against the configured allowed types.
Handled robust type alias resolution so that aliases like
`std::sync::LockResult` accurately map to their underlying `Adt` types
during lint evaluation.
Added UI tests in `tests/ui-toml/unwrap_used_allowed/` to verify both
allowed and disallowed cases.
----
changelog: [`unwrap_used`], [`expect_used`]: Add `allow-unwrap-types`
configuration to allow unwrapping specified types.
To be honest, the changes are confusing.
First of all, it has already been stated that it would be wrong if we
extended the lint to cover both sides.
https://github.com/rust-lang/rust-clippy/blob/18e5b2db4a3f9de20aa472d5c46a855e3a31d5c4/tests/ui/unnecessary_fold.rs#L91-L95
Secondly, there is some monstrous expression in the
`get_triggered_expr_span` function, and I think it could be rewritten
more cleanly.
Anyway, even if it has to be implemented, I'm glad to rewrite it more
thoroughly.
Fixesrust-lang/rust-clippy#16581.
----
changelog: [`unnecessary_fold`]: match against an accumulator on both
sides.
There is a proposal to change the behaviour of rustc's `must_use` lint
to consider `Result<T, U>` and `ControlFlow<U, T>` as `T` when `U` is
uninhabited. See <https://github.com/rust-lang/rust/pull/148214>.
This might make the user adding extra `#[must_use]` attributes to
functions returning `Result<T, !>` or `ControlFlow<!, T>`, which would
trigger the `double_must_use` lint in Clippy without the current change.
changelog: [`double_muse_use`, `drop_non_drop`,
`let_underscore_must_use`]: consider `Result<T, U>` and `ControlFlow<U,
T>` as `T` wrt the `#[must_use]` attribute if `U` is uninhabited.
There is a proposal to change the behaviour of rustc's `must_use` lint
to consider `Result<T, U>` and `ControlFlow<U, T>` as `T` when `U` is
uninhabited. See <https://github.com/rust-lang/rust/pull/148214>.
This might make the user adding extra `#[must_use]` attributes to
functions returning `Result<T, !>` or `ControlFlow<!, T>`, which would
trigger the `double_must_use` lint in Clippy without the current change.
Fixes: rust-lang/rust-clippy#16555
changelog: [unnecessary_min_or_max]: Fix false negatives for
usize::{MIN,MAX} by handling usize bit width correctly during constant
evaluation, enabling the lint to trigger on cases like n.min(0) /
n.max(usize::MAX).
This fixes a stale doc comment in `tests/compile-test.rs`.
`DiagnosticCollector` currently writes `util/gh-pages/index.html`, but
the
comment still referenced `util/gh-pages/lints.json`.
The drift came from b522e7a94 ("Generate lint list in HTML directly
instead
of JS"), which changed the output from JSON to HTML while leaving this
comment
unchanged.
changelog: none
DiagnosticCollector currently writes util/gh-pages/index.html, but the
doc comment still said util/gh-pages/lints.json.
The drift came from the switch to HTML generation in b522e7a94
("Generate lint list in HTML directly instead of JS"), which changed
the output file from lints.json to index.html but left this comment
unchanged.
Suggest removing an unnecessary trailing comma before the closing
parenthesis in single-line format-like macro invocations (e.g.
println!, format!, write!). The lint currently only runs on
format-like macros because it relies on format-argument parsing;
arbitrary user macros are not supported to avoid incorrect
suggestions.
- Lint is in the `style` group (allow-by-default)
- Single-line only: multi-line macro invocations are not linted
- Machine-applicable fix: removes the trailing comma
Remove "failed to resolve" and use the same format we use in other resolution errors "cannot find `name`".
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```