The applicability of `never_loop` is currently set to `Unspecified`, but
if the loop block does not contain `break` or `continue`, it can be
`MachineApplicable`.
changelog: [`never_loop`]: the applicability is now `MachineApplicable`
when the loop block contains neither `break` nor `continue`
fixes#13964
The lint `option_map_unwrap_or` used to have a similar issue in #10579,
so I borrowed its solution to fix this one.
changelog: [`option_if_let_else`]: fix FP when value partially moved
Commit efe3fe9b8c removed the ability for
`single_match` and `single_match_else` to trigger if comments were
present outside of the arms, as those comments would be lost while
rewriting the `match` expression.
This reinstates the lint, but prevents the suggestion from being applied
automatically in the presence of comments by using the `MaybeIncorrect`
applicability. Also, a note is added to the lint message to warn the
user about the need to preserve the comments if acting upon the
suggestion.
changelog: [`single_match`, `single_match_else`]: reinstate lint when
comments are inside the `match` but do not autofix the code
Fix#14418
Fixes https://github.com/rust-lang/rust-clippy/issues/14175.
There are two "big" cases to handle: `.map(|x| x.to_string())` and
`.map(String::to_string)`. If the closure has more than one expression,
we should not suggest `.cloned()`.
changelog: Improve `string_to_string` lint in case it is in a map call
r? @samueltardieu
Commit efe3fe9b8c removed the ability for
`single_match` and `single_match_else` to trigger if comments were
present outside of the arms, as those comments would be lost while
rewriting the `match` expression.
This reinstates the lint, but prevents the suggestion from being applied
automatically in the presence of comments by using the `MaybeIncorrect`
applicability. Also, a note is added to the lint message to warn the
user about the need to preserve the comments if acting upon the
suggestion.
close#12157
`needless_return` sometimes makes incorrect suggestions by omitting
necessary enclosing parentheses. This PR resolves the issue by using
`clippy_utils::sugg::Sugg`.
changelog: [`needless_return`]: now makes correct suggestions which
require enclosing parentheses
Fixes https://github.com/rust-lang/rust-clippy/issues/12163
I decided to initially make this a restriction lint because it felt a
bit niche and opinionated to be a warn-by-default style lint. It may be
appropriate as a style lint if the standard or convention *is* to use
`\` as doc comment linebreaks - not sure if they are!
The wording on the help message could be improved, as well as the name
of the lint itself since it's a bit wordy - suggestions welcome.
This lint works on both `///` and `//!` doc comments.
changelog: new lint: `doc_comment_double_space_linebreaks`
The lint for function calls was previously restricted to functions
taking exactly one argument. This was not documented.
Generalizing the lint to an arbitrary number of arguments in the
function call requires special casing some macro expansions from the
standard library. Macros such as `panic!()` or `assert_eq!()` exist
since Rust 1.0.0, but modern stdlib expand those macros into calls to
functions introduced in later Rust versions. While it is desirable to
lint code inside macros, using MSRV-incompatible functions coming from
`core` in macro expansions has been special-cased to not trigger this
lint.
Also, code coming from compiler desugaring may contain function calls
(for example, `a..=b` is now desugared into `RangeInclusive::new(a, b)`.
Those should not be linted either as the compiler is allowed to use
unstable function calls.
Fix#14212
changelog: [`incompatible_msrv`]: lint function calls with any argument
count
If types such as `Option<Option<String>>` are not used by value, then
`Option<Option<&String>>` will be suggested, instead of
`Option<&Option<String>>`.
fixes#13768
The existing implemention forgets to handle the binding mode (i.e. `ref`
and `ref mut`), so I just modified it to cover these cases.
changelog: [`manual_let_else`]: fix missing binding mode
Currently, If a struct is `pub` and its field is private, and
`avoid-breaking-exported-api = true` (default), then
`struct_field_names` will not lint the field, even though changing the
field’s name is not a breaking change. This is because the
breaking-exported-api condition was checking the visibility of the
struct, not its fields (perhaps because the same code was used for
enums). With this change, Clippy will check the field’s effective
visibility only.
Note: This change is large because some functions were moved into an
`impl` to be able to access more configuration. Consider viewing the
diff with whitespace ignored.
changelog: [`struct_field_names`]: also check private fields of public
structs
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the
prelude instead of importing or qualifying them.
These functions were added to all preludes in Rust 1.80.
Since the error kind (`io::ErrorKind::other`) is in the root context,
the error message must be found in the root context as well to compute
the correct span to remove.
Fix#14346
changelog: [`io_error_other`]: fix non-applicable suggestion
r? @llogiq
Currently, If a struct is `pub` and its field is private, and
`avoid-breaking-exported-api = true` (default), then `struct_field_names`
will not lint the field, even though changing the field’s name is not a
breaking change. This is because the breaking-exported-api condition was
checking the visibility of the struct, not its fields (perhaps because
the same code was used for enums). With this change, Clippy will check
the field’s effective visibility only.
Note: This change is large because some functions were moved into an
`impl` to be able to access more configuration. Consider viewing the
diff with whitespace ignored.
It can be error-prone for developers to manually change literals with
mixed uppercase and lowercase letters into consistently all-lowercase or
all-uppercase literals. Therefore, this lint rule should suggest
alternative literals.
changelog: [`mixed_case_hex_literals`]: add alternative suggestions
Since the error kind (`io::ErrorKind::other`) is in the root context,
the error message must be found in the root context as well to compute
the correct span to remove.
This PR:
- lints more case of raw pointer comparisons
- do not omit the named function to raw pointer conversion before
suggesting
- trigger the `ptr_eq` lint only if `cmp_null` doesn't trigger first, as
this is a more specialized version
- lints against `!=` in addition to `==`
The `ptr_eq` code has been moved from under `operators` to `ptr.rs`, in
order to benefit from factorization.
Fix#14337
changelog: [`ptr_eq`]: handle more cases
Closes#13306Closes#9925Closes#9470Closes#9305
Clippy gives wrong suggestions when the key is not `Copy`. As suggested
in #9925, in such cases Clippy will simply warn but no fix.
changelog: [`map_entry`]: fix wrong suggestions when key is not `Copy`
