Fixesrust-lang/rust-clippy#14750 by reducing the lint span for
needless_return.
changelog: [`needless_return`]: Lint span no longer wraps to previous
line
If a type is incomplete, for example if generic parameters are not
available yet, although they are not escaping, its layout may not be
computable. Calling `TyCtxt::layout_of()` would create a delayed bug in
the compiler.
changelog: [`zero_sized_map_values`]: fix ICE
Fixesrust-lang/rust-clippy#14822
r? @Jarcho
If a type is incomplete, for example if generic parameters are not
available yet, although they are not escaping, its layout may not
be computable. Calling `TyCtxt::layout_of()` would create a delayed bug
in the compiler.
A `return` in an expression makes it divergent and cannot be removed
blindly. While this stripping might have been introduced as a way to
catch more cases, it was improperly used, and no tests exhibit a failure
when this special handling is removed.
changelog: [`needless_match`]: do not strip `return` as it might make
the `if let` or `match` divergent in some cases
Fixesrust-lang/rust-clippy#14754
Fixes#13793.
Interestingly enough, to actually check that the macro call has at least
two arguments, we need to use the rust lexer after getting the original
source code snippet.
changelog: Add new `useless_concat` lint
It is not enough to check if an expression type implements `Drop` to
determine whether it can have a significant side-effect.
Also, add tests for unchecked cases which were explicitly handled in the
code, such as checking for side effect in a `struct`'s fields, or in its
base expression.
Fixrust-lang/rust-clippy#14592
changelog: [`no_effect_underscore_binding`]: do not propose to remove
the assignment of an object if dropping it might indirectly have a
visible side effect
Do not attempt to fetch a snippet from expansion. Without this change,
the inside of macros could[*] be shown as the source of the problem.
[*] Due to the way the source code is processed and reparsed in this
macro, the declarative macro has to be located outside the current
source file for the bug to appear. Otherwise, the macro call itself will
be (mis)identified as a potential `struct` field definition and the lint
will not trigger.
changelog: [`empty_struct_with_brackets`]: do not lint code coming from
macro expansion
A representation attribute `#[repr(…)]` might indicate that the ordering
of the fields or the variants is dictated by the API the code is
interfacing with. Better not lint with `arbitrary_source_item_ordering`
in this case.
changelog: [`arbitrary_source_item_ordering`]: do not lint inside items
with `#[repr]` attribute
fixes#12979fixes#12951fixes#13233
Tests still need to be finished and the docs still need to be updated,
but this should otherwise ready.
changelog: Lint `declare_interior_mutable_const` and
`borrow_interior_mutable_const` more precisely
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
