fixes: #12659
[`manual_map`] and [`manual_filter`] shares the same check logic, but
this issue doesn't seems like it could affect `manual_filter` (?)
---
changelog: make [`manual_map`] ignore types that contain `dyn`
An `if … { … } else { … }` used as the left operand of a binary
expression requires parentheses to be parsed as an expression.
Fix#11141
changelog: [`obfuscated_if_else`]: fix bug in suggestion by issuing
required parentheses around the left side of a binary expression
While extending the `option_map_or_err_ok` lint (warn by default,
"style") to recognize η-expanded forms of `Ok`, as in
```rust
// Should suggest `opt.ok_or("foobar")`
let _ = opt.map_or(Err("foobar"), |x| Ok(x));
```
I discovered that the `manual_ok_or` lint (allow by default, "pedantic")
already covered exactly the cases handled by `option_map_or_err_ok`,
including the one I was adding. Apparently, `option_map_or_err_ok` was
added without realizing that the lint already existed under the
`manual_ok_or` name. As a matter of fact, artifacts of this second lint
were even present in the first lint `stderr` file and went unnoticed for
more than a year.
This PR:
- deprecates `option_map_or_err_ok` with a message saying to use
`manual_ok_or`
- moves `manual_ok_or` from "pedantic" to "style" (the category in which
`option_map_or_err_ok` was)
In addition, I think that this lint, which is short, machine applicable,
and leads to shorter and clearer code with less arguments (`Ok`
disappears) and the removal of one level of call (`Err(x)` is replaced
by `x`), is a reason by itself to be in "style".
changelog: [`option_map_or_err_ok` and `manual_ok_or`]: move
`manual_ok_or` from "pedantic" to "style", and deprecate the redundant
style lint `option_map_or_err_ok`.
Removing the `.as_ref()` or `.as_mut()` as the top-level expression in a
closure may change the type of the result. In this case, it may be
better not to lint rather than proposing a fix that would not work.
changelog: [`useless_asref`]: do not remove the `.as_ref()` or
`.as_mut()` call if this would change the type of the enclosing closure
Fix#14088
Proposing to replace
```rust
let mut x = PathBuf::from("/foo");
x.push("/bar");
```
by
```rust
let mut x = PathBuf::from("/foo");
x.push("bar");
```
changes the content of `x` (`/bar` ⇒ `/foo/bar`). This is not equivalent
and should not be `MachineApplicable`, even if the original code is
suspicious.
changelog: none
Fix the version of `doc_overindented_list_items`. It actually will be in
1.86.0, not 1.80.0.
(https://github.com/rust-lang/rust/pull/136209 has a milestone of
1.86.0)
changelog: none
- `reindent_multiline()` always returns the result of
`reindent_multiline_inner()` which returns a `String`. Make
`reindent_multiline()` return a `String` as well, instead of a
systematically owned `Cow<'_, str>`.
- There is no reason for `reindent_multiline()` to force a caller to
build a `Cow<'_, str>` instead of passing a `&str` directly, especially
considering that a `String` will always be returned.
Also, both the input parameter and return value (of type `Cow<'_, str>`)
shared the same (elided) lifetime for no reason: this worked only
because the result was always the `Cow::Owned` variant which is
compatible with any lifetime.
As a consequence, the signature changes from:
```rust
fn reindent_multiline(s: Cow<'_, str>, …) -> Cow<'_, str> { … }
```
to
```rust
fn reindent_multiline(s: &str, …) -> String { … }
```
changelog: none
`MachineApplicable` is appropriate for the applicability of this lint.
changelog: [`if_then_some_else_none`]: change the applicability to
`MachineApplicable`
fixes#12407
I think it is meaningful to emit a warning even if the span is in a
macro.
changelog: [`manual_async_fn`]: don't emit suggestion inside macro
Counting in bytes for a pointer to `u8` is legitimate and must not
trigger the lint. Also, this prevents linting the
`{std,core}::ptr::write_bytes` as it manipulates bytes.
Fix#6590
changelog: [`size_of_in_element_count`]: do not lint if the pointee type
is `u8`
- `reindent_multiline()` always returns the result of
`reindent_multiline_inner()` which returns a `String`. Make
`reindent_multiline()` return a `String` as well, instead of a
systematically owned `Cow<'_, str>`.
- There is no reason for `reindent_multiline()` to force a caller to
build a `Cow<'_, str>` instead of passing a `&str` directly,
especially considering that a `String` will always be returned.
Also, both the input parameter and return value (of type `Cow<'_, str>`)
shared the same (elided) lifetime for no reason: this worked only because
the result was always the `Cow::Owned` variant which is compatible with
any lifetime.
As a consequence, the signature changes from:
```rust
fn reindent_multiline(s: Cow<'_, str>, …) -> Cow<'_, str> { … }
```
to
```rust
fn reindent_multiline(s: &str, …) -> String { … }
```
Hey folks. It's been a while since I added the `as_slice` method to
`Option`, and I totally forgot about a lint to suggest it. Well, I had
some time around Christmas, so here it is now.
---
changelog: add [`manual_option_as_slice`] lint
Convert two `rustc_middle::lint` functions to `Span` methods.
`rustc_middle` is a huge crate and it's always good to move stuff out of it. There are lots of similar methods already on `Span`, so these two functions, `in_external_macro` and `is_from_async_await`, fit right in. The diff is big because `in_external_macro` is used a lot by clippy lints.
r? ``@Noratrieb``
`rustc_middle` is a huge crate and it's always good to move stuff out of
it. There are lots of similar methods already on `Span`, so these two
functions, `in_external_macro` and `is_from_async_await`, fit right in.
The diff is big because `in_external_macro` is used a lot by clippy
lints.
A `ref` pattern applied to an argument is not ignored. It creates a
reference as expected, but still requires the function to take ownership
of the argument given to it.
