This PR fixes issues with the `missing_asserts_for_indexing` lint.
- false positive when the first index is the highest(or equal) value in
a list of indexes:
```rust
pub fn foo(slice: &[i32]) -> i32{
slice[1] * slice[0]
}
```
- false negative when an assert statement if found after the indexing
operation.
```rust
pub fn bar(slice: &[i32]) -> i32 {
let product = slice[0] * slice[1];
assert!(slice.len() > 1);
product
}
```
examples: https://godbolt.org/z/s7Y47vKdEcloses: #14079
changelog: [`missing_asserts_for_indexing`]: ignore asserts found after
indexing, and do not require asserts if the first index is highest.
Not all host tools platforms support `f16`/`f128` builtins yet due to
LLVM assertion failures and miscompilations. Until them, Clippy should
avoid using `f16`/`f128` at runtime itself. See
https://github.com/rust-lang/rust/issues/137630.
cc @tgross35
changelog: none
Move methods from `Map` to `TyCtxt`, part 5.
This eliminates all methods on `Map`. Actually removing `Map` will occur in a follow-up PR.
A follow-up to #137504.
r? `@Zalathar`
Various local trait item iteration cleanups
Adding a trait impl for `Foo` unconditionally affected all queries that are interested in a completely independent trait `Bar`. Perf has no effect on this. We probably don't have a good perf test for this tho.
r? `@compiler-errors`
I am unsure about https://github.com/rust-lang/rust/pull/139018/commits/9d05efb66f7b599eeacb5d2456f844fe4768e865 as it doesn't improve anything wrt incremental, because we still do all the checks for valid `Drop` impls, which subsequently will still invoke many queries and basically keep the depgraph the same.
I want to do
9549077a47/compiler/rustc_middle/src/ty/trait_def.rs (L141)
but would leave that to a follow-up PR, this one changes enough things as it is
Fixes#14488
Context: the `macro_metavars_in_unsafe` lint looks for unsafe blocks
with a macro span that then contain expressions with a root context span
(which means that it is a macro with an unsafe block expanding a
metavariable inside). In order to avoid emitting a warning for every
single macro invocation, it will deduplicate the unsafe blocks by the
span in the macro.
This leads to the linked issue where because of the deduplicating and
removing unsafe blocks that all belong to the same unsafe block in the
macro, only one of the unsafe blocks will actually have its lint
expectation fulfilled. This PR fixes that by manually fulfilling all of
the unsafe blocks from all expansions before deduplicating them.
changelog: [`macro_metavars_in_unsafe`]: fix unfulfilled `#[expect]` if
macro is invoked multiple times
remove `feature(inline_const_pat)`
Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck.
With https://github.com/rust-lang/types-team/issues/129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support `inline_const_pat` as they are implemented right now:
- we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types
- we want the inline const pattern to participate in exhaustiveness checking
- to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. **This is a query cycle**.
There are 4 possible ways to handle this:
- stop typechecking inline const patterns together with their parent
- causes inline const patterns to be different than inline const exprs
- prevents bidirectional inference, we need to either fail to compile `if let const { 1 } = 1u32` or `if let const { 1u32 } = 1`
- region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn
- inline consts no longer participate in exhaustiveness checking. Treat them like `pat if pat == const { .. }` instead. We then only evaluate them after borrowck
- difference between `const { 1 }` and `const FOO: usize = 1; match x { FOO => () }`. This is confusing
- do they carry their weight if they are now just equivalent to using an if-guard
- delay exhaustiveness checking until after borrowck
- should be possible in theory, but is a quite involved change and may have some unexpected challenges
- remove this feature for now
I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out.
`const { .. }`-expressions remain stable. These seem to have been the main motivation for https://github.com/rust-lang/rfcs/issues/2920.
r? types
cc `@rust-lang/types` `@rust-lang/lang` #76001
`ast::Item` has an `ident` field.
- It's always non-empty for these item kinds: `ExternCrate`, `Static`,
`Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`,
`Trait`, `TraitAlias`, `MacroDef`, `Delegation`.
- It's always empty for these item kinds: `Use`, `ForeignMod`,
`GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`.
There is a similar story for `AssocItemKind` and `ForeignItemKind`.
Some sites that handle items check for an empty ident, some don't. This
is a very C-like way of doing things, but this is Rust, we have sum
types, we can do this properly and never forget to check for the
exceptional case and never YOLO possibly empty identifiers (or possibly
dummy spans) around and hope that things will work out.
The commit is large but it's mostly obvious plumbing work. Some notable
things.
- `ast::Item` got 8 bytes bigger. This could be avoided by boxing the
fields within some of the `ast::ItemKind` variants (specifically:
`Struct`, `Union`, `Enum`). I might do that in a follow-up; this
commit is big enough already.
- For the visitors: `FnKind` no longer needs an `ident` field because
the `Fn` within how has one.
- In the parser, the `ItemInfo` typedef is no longer needed. It was used
in various places to return an `Ident` alongside an `ItemKind`, but
now the `Ident` (if present) is within the `ItemKind`.
- In a few places I renamed identifier variables called `name` (or
`foo_name`) as `ident` (or `foo_ident`), to better match the type, and
because `name` is normally used for `Symbol`s. It's confusing to see
something like `foo_name.name`.
By changing two of the fields to use `Option<Ident>` instead of `Ident`.
As a result, `None` now means "no identifier", which is much clearer
than using an empty identifier.
Having a macro call as the scrutinee is supported. However, the proposed
suggestion must use the macro call itself, not its expansion.
When the scrutinee is a macro call, do not complain about an irrefutable
match, as the user may not be aware of the result of the macro. A
comparaison will be suggested instead, as if we couldn't see the outcome
of the macro.
Similarly, do not accept macro calls as arm patterns.
changelog: [`single_match`]: proper suggestions in presence of macros
Fixes#14493
These method chains can be expressed concisely with `if` / `else`.
changelog: [`obfuscated_if_else`]: support `then().unwrap_or_default()`
and `then_some().unwrap_or_default()`
Having a macro call as the scrutinee is supported. However, the proposed
suggestion must use the macro call itself, not its expansion.
When the scrutinee is a macro call, do not complain about an irrefutable
match, as the user may not be aware of the result of the macro. A
comparaison will be suggested instead, as if we couldn't see the outcome
of the macro.
Similarly, do not accept macro calls as arm patterns.
This has two reasons: First of all we don't need the optimized MIR for
evaluating the checks of this lint, as const-eval anyways operates on
`mir_for_ctf` which is derived from `mir_drops_elaborated_and_const_checked`.
Second of all we might transform MIR in the optimization passes in a way
that doesn't work with const-eval, but it is irrelevant since const-eval
uses another MIR.
Specifically this came up when adding a new check in debug builds
(https://github.com/rust-lang/rust/pull/134424), which is added as part
of an optimization pass.
Until `if let` chains are stabilized, we do not collapse them together
or with other `if` expressions unless the `let_chains` feature is
enabled. This is the case for example in Clippy sources.
This was made possible by converting the `collapsible_if` to a late lint
to get access to the set of enabled features. This allows this PR to
supersede #14455 and no longer require an additional configuration
option.
The three commits are, in order:
- a conversion of the existing early lint to a late lint, with no new
feature or tests changes
- the addition of the `let_chains` feature detection and action, and
tests
- the application of the enhanced lint to Clippy sources (136 files
modified)
changelog: [`collapsible_if`]: recognize the rust compiler `let_chains`
feature
r? @flip1995
The `unnecessary_filter_map` and `unnecessary_find_map` lints were
making partial suggestions, proposing to replace the whole expression by
only the method name, or a subexpression which contained explicit
placeholders.
Since even `MaybeIncorrect` suggestions must generate code that
compiles, this changes those lints to recommandation lints with no
code suggestion.
Until `if let` chains are stabilized, we do not collapse them together
or with other `if` expressions unless the `let_chains` feature is
enabled. This is the case for example in Clippy sources.
When lowering a destructuring assignment from AST to HIR, the compiler
will reuse the same identifier name (namely `sym::lhs`) for all the
fields. The desugaring must be checked for to avoid a false positive of
the `shadow_unrelated` lint.
Fix#10279Fix#14377
changelog: [`shadow_unrelated`]: prevent false positive in destructuring
assignments
When lowering a destructuring assignment from AST to HIR, the compiler
will reuse the same identifier name (namely `sym::lhs`) for all the
fields. The desugaring must be checked for to avoid a false positive
of the `shadow_unrelated` lint.
