Checks for functions with method calls to `.map(_)` on an arg of type
`Option` as the outermost expression.
Fixes#774
```
changelog: [`single_option_map`]: Checks for functions with method calls to `.map(_)` on an arg of type `Option` as the outermost expression.
```
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
By assuming that a recursive type is normalizable within the deeper
calls to `is_normalizable_helper()`, more cases can be handled by this
function.
In order to fix stack overflows, a recursion limit has also been added
for recursive generic type instantiations.
Fix#9798Fix#10508Fix#11915
changelog: [`large_enum_variant`]: more precise detection of variants
with large size differences
Labeled blocks cannot be used as-is in the "then" or "else" part of an
`if` expression. They must be enclosed in an anonymous block.
Fix#14099
changelog: [`match_bool`]: fix suggestion when the rewritten block has a
label
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`
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
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.
Removing the semicolon of the last statement of an expressionless block
may change the block type even if the statement's type is `()`. If the
block type is `!` because of a systematic early return, typing it as
`()` may make it incompatible with the expected type for the block (to
which `!` is cast).
Fix#14100
changelog: [`unnecessary_semicolon`]: do not remove semicolon if it
could change the block type from `!` to `()`
Commit 2550530266 has extended the
`precedence` lint to include bitmasking and shift operations. The lint
is warn by default, and this generates many hits, especially in embedded
or system code, where it is very idiomatic to use expressions such as `1
<< 3 | 1 << 5` without parentheses.
This commit splits the recent addition into a new lint, which is put
into the "restriction" category, while the original one stays in
"complexity", because mixing bitmasking and arithmetic operations is
less typical.
Fix#14097
changelog: [`precedence_bits`]: new lint
Commit 2550530266 has extended the
`precedence` lint to include bitmasking and shift operations. The lint
is warn by default, and this generates many hits, especially in embedded
or system code, where it is very idiomatic to use expressions such as
`1 << 3 | 1 << 5` without parentheses.
This commit splits the recent addition into a new lint, which is put
into the "restriction" category, while the original one stays in
"complexity", because mixing bitmasking and arithmetic operations is
less typical.
Removing the semicolon of the last statement of an expressionless block
may change the block type even if the statement's type is `()`. If the
block type is `!` because of a systematic early return, typing it as
`()` may make it incompatible with the expected type for the block (to
which `!` is cast).
fix#13959
The current implementation of the `write_literal` and `print_literal`
lint performs escaping for the second argument of `write!` ,`writeln!`,
`print!` and `println!` of the suggestion by first replacing `"` with
`\"`, and then replacing `\` with `\\`. Performing these replacements in
this order may lead to unnecessary backslashes being added if the
original code contains `"` (e.g. `"` -> `\\"`), potentially resulting in
a suggestion that causes the code to fail to compile.
In the issue mentioned above, it’s suggested to use raw strings as raw
strings, but implementing this would require an ad-hoc change to the
current implementation, so it has been deferred. (I'll implement this in
another PR)
changelog: [`write_literal`]: fix incorrect escaping of suggestions
changelog: [`print_literal`]: fix incorrect escaping of suggestions
Add a new lint `doc_overindented_list_items` to detect and fix list items
in docs that are overindented.
For example,
```rs
/// - first line
/// second line
fn foo() {}
```
this would be fixed to:
```rs
/// - first line
/// second line
fn foo() {}
```
This lint improves readabiliy and consistency in doc.
