Was disabled in rust-lang/rust-clippy#10855 due to a broken suggestion.
This will only lint if a type is not proveded (e.g. `T::deref`).
changelog: none
Using the function declaration, by stripping the body, is enough to
convey the lint message.
changelog: [`unnecessary_wraps`]: do not include the whole body in the
lint span
Closesrust-lang/rust-clippy#14773
Clippy should not lint 2 blocks expression for comparison_chain.
Fixesrust-lang/rust-clippy#4725
changelog: [`comparison_chain`]: do not lint 2 blocks expression
When a `non_std_lazy_statics` warning is generated about an item type
which can be replaced by a standard library one, ensure that the lint
happens on the item HIR node so that it can be expected.
changelog: [`non_std_lazy_statics`]: generate the warning onto the right
node
Fixesrust-lang/rust-clippy#14729
Note that this doesn't change anything on lints generated for the
`lazy_static::lazy_static` macro because the `expect` attribute cannot
be applied to a macro.
Adds an internal lint to check for `#[derive(serde::Deserialize)]`
without
[`#[serde(deny_unknown_fields)]`](https://serde.rs/container-attrs.html#deny_unknown_fields).
Today, if you run Clippy with the following clippy.toml, Clippy will
produce a warning, but there will be no accompanying note:
```toml
# In the following configuration, "recommendation" should be "reason" or "replacement".
disallowed-macros = [
{ path = "std::panic", recommendation = "return a `std::result::Result::Error` instead" },
]
```
```sh
$ cargo clippy
Checking a v0.1.0 (/home/smoelius/tmp/a)
warning: use of a disallowed macro `std::panic`
--> src/lib.rs:2:5
|
2 | panic!();
| ^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#disallowed_macros
= note: `#[warn(clippy::disallowed_macros)]` on by default
```
The underlying problem is: the enum that derives `serde::Deserialize`
([`DisallowedPathEnum`](81643e297c/clippy_config/src/types.rs (L47)))
does not have the attribute `#[serde(deny_unknown_fields)]`.
This lint identifies such problems by checking trait `impl`s. An
alternative I considered was to walk `clippy_config::conf::Conf`
directly. However, that would not catch the `DisallowedPathEnum` case
because it [is not used in `Conf`
directly](81643e297c/clippy_config/src/types.rs (L31)).
Just to be clear, no one asked for this. So I hope the maintainers do
not mind.
changelog: none
Added lint for catching `&[foo.clone()]` where foo is a reference and
suggests `std::slice::from_ref(foo)`.
changelog: new lint: [`cloned_ref_to_slice_refs`]
changelog: [`type_repetition_in_bounds`]: include all generic bounds in
suggestion, clearer message which now includes the repeated type name
Fixesrust-lang/rust-clippy#14744
If an expression is not going to return from the current function of
closure, it should not get linted.
This also allows `return` expression to be linted, in addition to the
final expression. Those require blockification and proper indentation.
changelog: [`return_and_then`]: only lint returning expressions
Fixesrust-lang/rust-clippy#14781
Fixes https://github.com/rust-lang/rust-clippy/issues/13973.
I don't think we can make `fn_to_numeric_cast_any` to be emitted in some
special cases. Its category cannot be changed at runtime.
I think in this case, the best might be a specialized new lint so we can
target exactly what we want.
----
changelog: Add new `confusing_method_to_numeric_cast` lint
`tempfile` has deprecated `TempDir::into_path()` (replacing it by
`TempDir::keep()`) between version `3.3` which Clippy required and version
`3.20.0` which is the latest semver-compatible version. Since Clippy
doesn't use a `Cargo.lock` file, the latest version of `tempfile` is
used which leads to CI failure.
If an expression is not going to return from the current function of
closure, it should not get linted.
This also allows `return` expression to be linted, in addition to the
final expression. Those require blockification and proper indentation.
The `mir_drops_elaborated_and_const_checked` query result has been
stolen already and cannot be borrowed again. Use the `optimized_mir`
query result instead.
The problem is that `check_fn` is triggered by both function and
closure, and `visit_expr` can visit expressions in another closures
within a function or closure.
So just skip walking in a inner closure.
changelog: Fix [`unnecessary_unwrap`] emitted twice in closure which
inside in a function or another closure.
Fixes: rust-lang/rust-clippy#14763
Closesrust-lang/rust-clippy#14598
Implemented checks for simple enum variants when checking if match arms
are disjointed.
changelog: [`manual_let_else`] fix FN when diverges on simple enum
variant
Where you would previously see
```
error: some lint
--> src/lib.rs:1:2
```
it will now print
```
error: some lint
--> clippy_lints/src/lib.rs:1:2
```
Ensuring you can click the link in the terminal
A workaround for us not being in a workspace
changelog: none
We could do with a way to make matching on the `assert_*` macro kind
easier, this came up a bunch here. I'll take a look at that as a follow
up
changelog: none
changelog: [`unwrap_used`, `expect_used`]: lint even when the receiver
is a macro expansion result
This also paves the way for expanding more method call lints to expanded
receivers or arguments.
Fixesrust-lang/rust-clippy#13455
When a `non_std_lazy_statics` warning is generated about an item type which
can be replaced by a standard library one, ensure that the lint happens on
the item HIR node so that it can be expected.
fixrust-lang/rust-clippy#13637
As suggested in the PR above, we should not lint enum variants
containing matching path names.
changelog: [`item_name_repetitions`]: exclude enum variants with
identical path components
fixes#14413
add allow_unused config to missing_docs_in_private_items for underscored
field
changelog: [`missing_docs_in_private_items`]: add allow_unused config to
missing_docs_in_private_items for underscored field
Explaination (quoted from the issue's author): When writing structures
that must adhere to a specific format (such as memory mapped I/O
structures) there are inevitably fields that are "reserved" by
specifications and thus need no documentation. In cases where private
docs are preferred but reserved fields need no explanation, having to
#[allow/expect] this lint removes the ability to check for otherwise
used fields' documentation.
