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
Now that `if let` chains have been introduced, the `if_chain` external
crate is no longer necessary. Dropping special support for it also
alleviates the need to keep the crate as a dependency in tests.
This is a cleanup PR.
changelog: none
base check
same fields different struct
reordered fields
different paths to the same struct
same for tuple structs
style: use `zip`-the-function all over the place
makes the code a bit more concise by removing the need for explicit
`.iter()`
style: move precondition checking to the match guard
the match arms above put the "sanity" checks in the guard, and call only
`check_pat` in the body. With this commit, the (tuple) struct cases
follow that convention as well. Well, almost -- I think the ident check
belongs to the second category of checks, so I put it in the body as
well
misc: use `None` in the pattern directly
this'll probably be marginally faster thanks to the equality check being
now structural
move the tests to the right file
Deduplicate `IntTy`/`UintTy`/`FloatTy`.
There are identical definitions in `rustc_type_ir` and `rustc_ast`. This commit removes them and places a single definition in `rustc_ast_ir`. This requires adding `rust_span` as a dependency of `rustc_ast_ir`, but means a bunch of silly conversion functions can be removed.
r? `@fmease`
There are identical definitions in `rustc_type_ir` and `rustc_ast`. This
commit removes them and places a single definition in `rustc_ast_ir`.
This requires adding `rust_span` as a dependency of `rustc_ast_ir`, but
means a bunch of silly conversion functions can be removed.
The one annoying wrinkle is that the old version had differences in
their `Debug` impls, e.g. one printed `u32` while the other printed
`U32`. Some compiler error messages rely on the former (yuk), and some
clippy output depends on the latter. So the commit also changes clippy
to not rely on `Debug` and just implement what it needs itself.
When an expression is made of a `!` or `-` unary operator which does not
change the type of the expression, use a new variant in `Sugg` to denote
it. This allows replacing an extra application of the same operator by
the removal of the original operator instead.
Some suggestions will now be shown as `x` instead of `!!x`. Right now,
no suggestion seems to produce `--x`.
changelog: none
When an expression is made of a `!` or `-` unary operator which does not
change the type of the expression, use a new variant in `Sugg` to denote
it. This allows replacing an extra application of the same operator by
the removal of the original operator instead.
Also, when adding a unary operator to a suggestion, do not enclose the
operator argument in parentheses if it starts with a unary operator
itself unless it is a binary operation (including `as`), because in this
case parentheses are required to not bind the lhs only.
Some suggestions will now be shown as `x` instead of `!!x`. Right now,
no suggestion seems to produce `--x`.
Now that `if let` chains have been introduced, the `if_chain` external
crate is no longer necessary. Dropping special support for it also
alleviates the need to keep the crate as a dependency in tests.
The useless_attribute lint was incorrectly flagging #[expect(redundant_imports)]
as useless when applied to macro re-exports. This occurred because the lint
didn't recognize 'redundant_imports' as a valid rustc lint name.
This commit:
- Adds 'redundant_imports' to the list of known rustc lints in sym.rs
- Updates the useless_attribute lint to properly handle this case
- Adds a regression test to prevent future false positives
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.
Fix several issues with `manual_is_multiple_of`
- `&a % &b == 0` compiles, but requires dereferencing `b` when replacing
with `a.is_multiple_of(b)`.
- In `a % b == 0`, if type of `a` is not certain, `a.is_multiple_of(b)`
might not be typable.
- In `a % b == 0`, `a` and `b` must be unsigned integers, not any
arbitrary types implementing `Rem` and outputing an integer.
Those fixes have required increasing the precision of type certainty
determination in the two first patches.
Fixesrust-lang/rust-clippy#15203Fixesrust-lang/rust-clippy#15204
changelog: [`manual_is_multiple_of`]: fix various false positive
de-duplicate condition scoping logic between AST→HIR lowering and `ScopeTree` construction
There was some overlap between `rustc_ast_lowering::LoweringContext::lower_cond` and `rustc_hir_analysis::check::region::resolve_expr`, so I've removed the former and migrated its logic to the latter, with some simplifications.
Consequences:
- For `while` and `if` expressions' `let`-chains, this changes the `HirId`s for the `&&`s to properly correspond to their AST nodes. This is how guards were handled already.
- This makes match guards share previously-duplicated logic with `if`/`while` expressions. This will also be used by guard pattern[^1] guards.
- Aside from legacy syntax extensions (e.g. some builtin macros) that directly feed AST to the compiler, it's currently impossible to put attributes directly on `&&` operators in `let` chains[^2]. Nonetheless, attributes on `&&` operators in `let` chains in `if`/`while` expression conditions are no longer silently ignored and will be lowered.
- This no longer wraps conditions in `DropTemps`, so the HIR and THIR will be slightly smaller.
- `DesugaringKind::CondTemporary` is now gone. It's no longer applied to any spans, and all uses of it were dead since they were made to account for `if` and `while` being desugared to `match` on a boolean scrutinee.
- Should be a marginal perf improvement beyond that due to leveraging [`ScopeTree` construction](5e749eb66f/compiler/rustc_hir_analysis/src/check/region.rs (L312-L355))'s clever handling of `&&` and `||`:
- This removes some unnecessary terminating scopes that were placed around top-level `&&` and `||` operators in conditions. When lowered to MIR, logical operator chains don't create intermediate boolean temporaries, so there's no temporary to drop. The linked snippet handles wrapping the operands in terminating scopes as necessary, in case they create temporaries.
- The linked snippet takes care of letting `let` temporaries live and terminating other operands, so we don't need separate traversals of `&&` chains for that.
[^1]: rust-lang/rust#129967
[^2]: Case-by-case, here's my justification: `#[attr] e1 && e2` applies the attribute to `e1`. In `#[attr] (e1 && e2)` , the attribute is on the parentheses in the AST, plus it'd fail to parse if `e1` or `e2` contains a `let`. In `#[attr] expands_to_let_chain!()`, the attribute would already be ignored (rust-lang/rust#63221) and it'd fail to parse anyway; even if the expansion site is a condition, the expansion wouldn't be parsed with `Restrictions::ALLOW_LET`. If it *was* allowed, the notion of a "reparse context" from https://github.com/rust-lang/rust/issues/61733#issuecomment-509626449 would be necessary in order to make `let`-chains left-associative; multiple places in the compiler assume they are.
fix: Include frontmatter in -Zunpretty output
In the implementation (rust-lang/rust#140035), this was left as an open question for
the tracking issue (rust-lang/rust#136889). My assumption is that this should be
carried over.
The test was carried over from rust-lang/rust#137193 which was superseded by rust-lang/rust#140035.
Thankfully, either way, `-Zunpretty` is unstable and we can always
change it even if we stabilize frontmatter.
<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
