combine two similar arms
use in `eager_transmute`
use in `double_ended_iterator_last`
use different numbers in the new test case to avoid possible confusion
move the other "unfixable" case as well; it shouldn't lint anyway, so
having it in the main test file is fine
There are many places that join path segments with `::` to produce a
string. A lot of these use `join("::")`. Many in rustdoc use
`join_with_double_colon`, and a few use `.joined("..")`. One in Clippy
uses `itertools::join`. A couple of them look for `kw::PathRoot` in the
first segment, which can be important.
This commit introduces `rustc_ast::join_path_{syms,ident}` to do the
joining for everyone. `rustc_ast` is as good a location for these as
any, being the earliest-running of the several crates with a `Path`
type. Two functions are needed because `Ident` printing is more complex
than simple `Symbol` printing.
The commit also removes `join_with_double_colon`, and
`estimate_item_path_byte_length` with it.
There are still a handful of places that join strings with "::" that are
unchanged. They are not that important: some of them are in tests, and
some of them first split a path around "::" and then rejoin with "::".
This fixes one test case where `{{root}}` shows up in an error message.
To avoid false positives, the `range_plus_one` and `range_minus_one`
lints will restrict themselves to situations where the iterator types
can be easily switched from exclusive to inclusive or vice-versa. This
includes situations where the range is used as an iterator, or is used
for indexing.
On the other hand, assignments of the range to variables, including
automatically typed ones or wildcards, will no longer trigger the lint.
However, the cases where such an assignment would benefit from the lint
are probably rare.
In a second commit, the `range_plus_one` and `range_minus_one` logic are
unified, in order to properly emit parentheses around the suggestion
when needed.
Fixrust-lang/rust-clippy#3307Fixrust-lang/rust-clippy#9908
changelog: [`range_plus_one`, `range_minus_one`]: restrict lint to cases
where it is safe to switch the range type
*Edit:* as a consequence, this led to the removal of three
`#[expect(clippy::range_plus_one)]` in the Clippy sources to avoid those
false positives.
Previously expect_fun_call would too eagerly convert cases like
`foo.expect(if | block | match)` into `foo.unwrap_or_else`.
Additionally, it would also add to_string() even though the argument is
being passed into format!() which can accept a &str. I also discovered
some other cases where this lint would either produce invalid results,
or be triggered unnecessarily:
- Clippy would suggest changing expect to unwrap_or_else even if the
expression inside expect contains a return statement
- opt.expect(const_fn()) no longer triggers the lint
- The lint would always add braces to the closure body, even if the body
of expect is a single expression
- opt.expect({"literal"}) used to get turned into
```opt.unwrap_or_else(|| panic!("{}", {"literal"}.to_string()))```
Fixesrust-lang/rust-clippy#15056
changelog: [`expect_fun_call`]: fix expect_fun_call producing invalid
suggestions
<strike>blocked on rust-lang/rust-clippy#15073</strike>
Lint method calls inside `map_or` too, so for this, lint will be showed:
```rust
Some(4).map_or("asd".to_string().len() as i32, f);
```
previously it worked only for:
```rust
Some(4).map_or(slow_fun(), f);
```
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=bfcda42a6af446e69bc883a8b45eb13c
Sorry for multiple `or_fun_call` PRs.
changelog: [`or_fun_call`]: lint method calls inside map_or first arg
When comparing `x.map(func) == Some(bool_lit)`, the value of `bool_lit`
was ignored, despite the fact that its value should determine the value
of the proposed expression.
`func` can be either a closure or a path. For the latter, η-expansion
will be used if needed to invert the result of the function call.
changelog: [`manual_is_variant_and`]: fix inverted suggestions that
could lead to code with different semantics
Fixesrust-lang/rust-clippy#15202
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
-
[Beta-nomination](https://github.com/rust-lang/rust-clippy/pull/15206#issuecomment-3034006613)
by [samueltardieu](https://github.com/samueltardieu)
*Managed by `@rustbot`—see
[help](https://forge.rust-lang.org/triagebot/note.html) for details*
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
Propose to replace `x.map_or(false, |y| y == z)` by `x == Some(z)` only
if `x` is not adjusted. Otherwise, the type of `x` in the comparaison
may not be the expected one, as it may be the product of an auto-deref.
changelog: [`unnecessary_map_or`]: do not propose to replace the
`map_or` call by a comparaison if types wouldn't be correct
Fixesrust-lang/rust-clippy#15180
When comparing `x.map(func) == Some(bool_lit)`, the value of `bool_lit` was
ignored, despite the fact that its value should determine the value of
the proposed expression.
`func` can be either a closure or a path. For the latter, η-expansion
will be used if needed to invert the result of the function call.
<strike>build on top of rust-lang/rust-clippy#15071</strike>
This also adds ability to lint Option/Result::and method. Yes, this is
not `or` method, but uses the same eager/lazy linting logic. Should i
update lint description to list all checked structs/methods?
changelog: [`or_fun_call`]: lint Option/Result::and
The `TyCtxt::hir_get_fn_id_for_return_block()` function was too broad,
as it will return positively even when given part of an expression that
can be used as a return value. A new
`potential_return_of_enclosing_body()` utility function has been made to
represent the fact that an expression might be directly returned from
its enclosing body.
changelog: [`return_and_then`]: prevent false positives in case of a
partially used expression
Fixesrust-lang/rust-clippy#15111Fixesrust-lang/rust-clippy#14927
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
-
[Beta-nomination](https://github.com/rust-lang/rust-clippy/pull/15115#issuecomment-2996222332)
by [samueltardieu](https://github.com/samueltardieu)
*Managed by `@rustbot`—see
[help](https://forge.rust-lang.org/triagebot/note.html) for details*
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
Propose to replace `x.map_or(false, |y| y == z)` by `x == Some(z)` only
if `x` is not adjusted. Otherwise, the type of `x` in the comparaison
may not be the expected one, as it may be the product of an auto-deref.
It's like `Symbol` but for byte strings. The interner is now used for
both `Symbol` and `ByteSymbol`. E.g. if you intern `"dog"` and `b"dog"`
you'll get a `Symbol` and a `ByteSymbol` with the same index and the
characters will only be stored once.
The motivation for this is to eliminate the `Arc`s in `ast::LitKind`, to
make `ast::LitKind` impl `Copy`, and to avoid the need to arena-allocate
`ast::LitKind` in HIR. The latter change reduces peak memory by a
non-trivial amount on literal-heavy benchmarks such as `deep-vector` and
`tuple-stress`.
`Encoder`, `Decoder`, `SpanEncoder`, and `SpanDecoder` all get some
changes so that they can handle normal strings and byte strings.
This change does slow down compilation of programs that use
`include_bytes!` on large files, because the contents of those files are
now interned (hashed). This makes `include_bytes!` more similar to
`include_str!`, though `include_bytes!` contents still aren't escaped,
and hashing is still much cheaper than escaping.
If there are more than one dereference (there is one corresponding
matched with a borrow in any case), consider that the argument might
point to a place expression, which is the safest choice.
Also, use an appropriate number of dereferences in suggestions involving
arguments using themselves multiple dereferences.
The `TyCtxt::hir_get_fn_id_for_return_block()` function was too broad,
as it will return positively even when given part of an expression that can
be used as a return value. A new `potential_return_of_enclosing_body()`
utility function has been made to represent the fact that an expression
might be directly returned from its enclosing body.
To limit false positives, the `range_plus_one` and `range_minus_one` lints
will restrict themselves to situations where the iterator types can be easily
switched from exclusive to inclusive or vice-versa. This includes situations
where the range is used as an iterator, or is used for indexing. Also,
when the range is used as a function or method call argument and the
parameter type is generic over traits implemented by both kind of
ranges, the lint will trigger.
On the other hand, assignments of the range to variables, including
automatically typed ones or wildcards, will no longer trigger the lint.
However, the cases where such an assignment would benefit from the lint
are probably rare.
This fix doesn't prevent false positives from happening. A more complete
fix would check if the obligations can be satisfied by the new proposed
range type.
