Suggest using equality comparison instead of pattern matching on non-structural constant in pattern
When encountering a pattern containing a non-structural constant (not marked as `#[derive(PartialEq)]` to make it suitable for pattern matching, `C` in the examples below), we would previously not provide additional guidance. With this PR, the `help` in the following examples are added:
```
error: constant of non-structural type `partial_eq::S` in a pattern
--> $DIR/suggest_equality_comparison_instead_of_pattern_matching.rs:16:18
|
LL | struct S;
| -------- `partial_eq::S` must be annotated with `#[derive(PartialEq)]` to be usable in patterns
...
LL | const C: S = S;
| ---------- constant defined here
...
LL | Some(C) => {}
| ^ constant of non-structural type
|
note: the `PartialEq` trait must be derived, manual `impl`s are not sufficient; see https://doc.rust-lang.org/stable/std/marker/trait.StructuralPartialEq.html for details
--> $DIR/suggest_equality_comparison_instead_of_pattern_matching.rs:5:5
|
LL | impl PartialEq<S> for S {
| ^^^^^^^^^^^^^^^^^^^^^^^
help: add a condition to the match arm checking for equality
|
LL - Some(C) => {}
LL + Some(binding) if binding == C => {}
|
```
```
error: constant of non-structural type `partial_eq::S` in a pattern
--> $DIR/suggest_equality_comparison_instead_of_pattern_matching.rs:22:18
|
LL | struct S;
| -------- `partial_eq::S` must be annotated with `#[derive(PartialEq)]` to be usable in patterns
...
LL | const C: S = S;
| ---------- constant defined here
...
LL | let Some(C) = Some(S) else { return; };
| ^ constant of non-structural type
|
note: the `PartialEq` trait must be derived, manual `impl`s are not sufficient; see https://doc.rust-lang.org/stable/std/marker/trait.StructuralPartialEq.html for details
--> $DIR/suggest_equality_comparison_instead_of_pattern_matching.rs:5:5
|
LL | impl PartialEq<S> for S {
| ^^^^^^^^^^^^^^^^^^^^^^^
help: check for equality instead of pattern matching
|
LL - let Some(C) = Some(S) else { return; };
LL + if Some(C) == Some(S) { return; };
|
```
The suggestion accounts for a few conditions:
- if the type is not from the local crate and has no `PartialEq` impl, the user can't make it structural, so we don't provide the suggestion
- regardless of whether the type is local or remote, if it has a manual `PartialEq`, explain that with a derived `PartialEq` you could use equality
- if the type is local and has no impl, suggest adding a derived `PartialEq` and use equality check instead of pattern matching
- when suggesting equality, account for `if-let` to suggest chaining (edition dependent), `match` arm with a present `if` check, `match` arm without an existing `if` check
- when encountering `let-else`, we suggest turning it into an `if` expression instead (this doesn't check for additional bindings beyond the constant, which would suggest incorrect code in some more complex cases).
Fixrust-lang/rust#42753.
Require avxvnni for avx10.2
AVX10.2 supports masked (and 512-bit) versions of some intrinsics available in AVXVNNI, AVXVNNIINT8 and AVXVNNIINT16 (e.g. AVX10.2 introduces `_mm{,256,512}_{mask{z}}_dpbuud_epi32` corresponding to `_mm{,256}_dpbuud_epi32` from AVXVNNIINT8). But Intel (being Intel), didn't (at least not in SDM) enforce that AVX10.2 (or at least AVX10_VNNI_INT, which is a "discrete AVX10 feature", introduced alongside AVX10.2, and expected to house more such instructions) requires AVXVNNI etc.
To make this (admittedly very Intel) situation a bit better, we can just require these features from the Rust frontend
r? @Amanieu
This also corrects a mistake in std-detect which allowed AVX10 to be enabled without AVX512F, in the (odd) case when F16C or FMA are not available (we require these for AVX512F because otherwise the LLVM assembler doesn't work)
rustc_expand: improve diagnostics for non-repeatable metavars
There was an initally opened pr which solve this issue here https://github.com/rust-lang/rust/pull/152679. It got merged but, there was a perf regression. And this new pr is opened to address the problem. The first did the computation of binding and matched_rule and then passed them as owned value down to `diagnostics::emit_frag_parse_err(` but, now this pr address the issue by passing `lhs` and `rules` as borrowed value to from_tts and the move the logic to `diagnostics::emit_frag_parse_err(`.
Fix https://github.com/rust-lang/rust/issues/47452.
Add functions to `GrowableBitSet`
Only really need `insert_range` for clippy, but may as well add the others. Using `Range` instead of `RangeBounds` since an end bound is needed for this to make sense and there aren't any traits to enforce that.
delegation: don't propagate synthetic params, remove lifetime hacks
Some small fixes after new delegation lowering was merged: remove lifetime hacks as now we get only early-bound lifetimes from generics, don't propagate synthetic generic params as now we know that they are synthetic. Fixesrust-lang/rust#143498. Part of rust-lang/rust#118212.
r? @petrochenkov
delegation: fix zero-args nested delegation ICE
This PR fixes an ICE when during lowering of nested delegation we need to access information about its parent, who is also inside body of another delegation. As a fix we lower delegation body even if there are no arguments in signature function, in this case we will see an error `this function takes 0 arguments but 1 argument was supplied`. Fixesrust-lang/rust#154332. Part of rust-lang/rust#118212.
r? @petrochenkov
Overhaul `Erasable` impls
This PR removes many unused `Erasable` impls, converts many of the hand-written impls to macro-generated impls, and sorts the macro's inputs. This cuts over 200 lines of code and fixes three FIXME comments.
r? @petrochenkov
miri recursive validation: only check one layer deep
As has been proposed in https://github.com/rust-lang/unsafe-code-guidelines/issues/414, let's see what happens if we make recursive checking in Miri shallow: we treat whatever is behind a reference as if it was inside `MaybeDangling`, which means nested references do not have to be dereferenceable.
This changes the meaning of the original flag -- I don't think it is worth supporting multiple variants of recursive checking (it'd require a bunch of new plumbing), and this seems to be the strictest variant that still has any traction in the discussion.
interpret: when passing an argument fails, point at that argument
For a long time now, we did some contortions so that when something goes wrong while initializing the arguments for a function, we point at the call site rather than the callee. Historically, this had to be done because the "current location" in the callee pointed at the first instruction, which would obviously be nonsense. A while ago we gained the ability in the interpreter for the "current location" to be just a span that we point at for errors, but we never reevaluated the decision for how spans are handled during function calls. (We did use this "just a span" location for [errors during the initial stack frame setup](https://github.com/rust-lang/rust/commit/d21e0118d0eefc8b0073fa47fa16699d37047abf), but not for argument initialization.)
There's no always-great choice for pointing at the caller vs the callee: when they disagree about the type of an argument, either side could be wrong. If We do *two* typed copies in that case, one at the caller type and one at the callee type. Arguably we should point at the one that goes wrong, but we don't have a good way to expose that.
What ultimately pushed me over the edge towards pointing at the callee are two points:
- This provides strictly more information. if we point at the callee, the caller is available in the stacktrace. But if we point at the caller, then it might be impossible to figure out the actual callee if a function pointer or dyn call is involved.
- As part of resolving some long-standing questions around retags I am moving retagging to become part of validation, which means the retag and protector initialization of function arguments will happen during argument initialization. These currently point at the argument inside the callee, which I think is strictly preferable for these errors.
The diff will be much smaller with whitespace changes hidden.
debuginfo: emit DW_TAG_call_site entries
Set `FlagAllCallsDescribed` on function definition DIEs so LLVM emits DW_TAG_call_site entries, letting debuggers and analysis tools track tail calls.
Add macro matcher for `guard` fragment specifier
Tracking issue #153104
This PR implements a new `guard` macro matcher to match `if-let` guards (specifically [`MatchArmGuard`](https://github.com/rust-lang/reference/blob/50a1075e879be75aeec436252c84eef0fad489f4/src/expressions/match-expr.md#match-guards)). In the upcoming PR, we can use this new matcher in the `matches!` and `assert_matches!` macros to support their use with `if-let` guards. (see #152313)
The original `Expr` used to represent a guard has been wrapped in a new `Guard` type, allowing us to carry the span information of the leading `if` keyword. However, it might be even better to include the `if` keyword in the `Guard` type as well? I've left a FIXME comment in the code.
Add `-Zsanitize=kernel-hwaddress`
The Linux kernel has a config option called `CONFIG_KASAN_SW_TAGS` that enables `-fsanitize=kernel-hwaddress`. This is not supported by Rust.
One slightly awkward detail is that `#[sanitize(address = "off")]` applies to both `-Zsanitize=address` and `-Zsanitize=kernel-address`. Probably it was done this way because both are the same LLVM pass. I replicated this logic here for hwaddress, but it might be undesirable.
Note that `#[sanitize(kernel_hwaddress = "off")]` could be supported as an annotation on statics, but since it's also missing for `#[sanitize(hwaddress = "off")]`, I did not add it.
MCP: https://github.com/rust-lang/compiler-team/issues/975
Tracking issue: https://github.com/rust-lang/rust/issues/154171
cc @rcvalle @maurer @ojeda
Some of the hand-written `Erasable` impls only match a single type in
practice. It's easier to just list the concrete types in
`impl_erasable_for_types_with_no_type_params!`.
Now that 'static lifetimes aren't used, a lot of the hand-written
`Erasable` impls can now be done with the macro. (The only ones that
can't are those with a generic type parameter, because `size_of`
doesn't work in that case.)
Also, `impl_erasable_for_single_lifetime_types!` isn't needed at all.
constify const Fn*: Destruct
makes closures const destruct where their upvars are. i think this makes sense
and is how this should be implemented.
r? @oli-obk
Unalign `PackedFingerprint` on all hosts, not just x86 and x86-64
Back in https://github.com/rust-lang/rust/pull/78646, `DepNode` was modified to store an unaligned `PackedFingerprint` instead of an 8-byte-aligned `Fingerprint`. That reduced the size of DepNode from 24 bytes to 17 bytes (nowadays 18 bytes), resulting in considerable memory savings in incremental builds.
See https://github.com/rust-lang/rust/pull/152695#issuecomment-3907091509 for a benchmark demonstrating the impact of *removing* that optimization.
At the time (and today), the unaligning was only performed on x86 and x86-64 hosts, because those CPUs are known to generally have low overhead for unaligned memory accesses. Hosts with other CPU architectures would continue to use an 8-byte-aligned fingerprint and a 24-byte DepNode.
Given the subsequent rise of aarch64 (especially on macOS) and other architectures, it's a shame that some commonly-used builds of rustc don't get those memory-size benefits, based on a decision made several years ago under different circumstances.
We don't have benchmarks to show the actual effect of unaligning DepNode fingerprints on various non-x86 hosts, but it seems very likely to be a good idea on Apple chips, and I have no particular reason to think that it will be catastrophically bad on other hosts. And we don't typically perform this kind of speculative pessimization in other parts of the compiler.
Delegation: eliminate usage of AST from generics creation
This PR eliminates all interaction with AST during creation of generics, then it supports proper const param types propagation. Fixesrust-lang/rust#153433. Fixesrust-lang/rust#153499. Part of rust-lang/rust#118212.
r? @petrochenkov
fix/extend some mir-opt comments
Looks like CopyProp was refactored without updating that comment.
And for GVN, I think this is what you had in mind @cjgillot but would be great if you could have a look.
Defer codegen for the VaList Drop impl to actual uses
This allows compiling libcore with codegen backends that don't actually implement VaList like cg_clif.
Use a safe `BucketIndex` abstraction in `VecCache`
The current code for indexing into bucket arrays is quite tricky and unsafe, partly because it has to keep manually assuring the compiler that a bucket index is always less than 21.
By encapsulating that knowledge in a 21-value enum, we can make the code clearer and safer, without giving up performance.
Having a dedicated `BucketIndex` type could also help with further cleanups of `VecCache` indexing.
Link LLVM dynamically on aarch64-apple-darwin
Follow-up to rust-lang/rust#152768.
* Link LLVM dynamically on MacOS
* Fix a macOS LLVM dylib name mismatch
bors