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.
Migrate UI tests
In this pull request, I am migrating the following files and adding a comment at the top, including a link to the issue they were regression tests for:
- `tests/ui/issues/issue-4735.rs` ➝ `tests/ui/drop/drop-noncopyable-raw-pointer.rs`
- `tests/ui/issues/issue-17734.rs` ➝ `tests/ui/codegen/box-str-drop-glue.rs`
r? Kivooeo
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.
fromrangeiter-overflow-checks: accept optional `signext` for argument
On some targets such as LoongArch64 and RISCV64, the ABI requires sign-extension for 32-bit integer arguments, so LLVM may emit the `signext` attribute for the `%range` parameter. The existing CHECK pattern required the argument to be exactly `i32 noundef %range`, causing the test to fail on those targets.
Allow an optional `signext` attribute in the CHECK pattern so the test passes consistently across architectures without affecting the intended codegen validation.
install-template.sh: Optimize by using Bourne shell builtins.
This replaces forking separate processes and using "cut" with Bourne shell builtin operations for "remove largest suffix pattern" and "remove smallest prefix pattern" operations.
This is the follow-up of https://github.com/rust-lang/rust/pull/145809
Move ui/issues tests to relevant subdirectories
Related to https://github.com/rust-lang/rust/issues/133895 and [Reorganisation of tests/ui/issues for GSOC](https://github.com/rust-lang/google-summer-of-code?tab=readme-ov-file#reorganisation-of-testsuiissues)
This is the first PR in a batch of PRs.
Moves `ui/issues/issue-17546.rs` -> `ui/variants/variant-result-noresult-used-as-type.rs`
Approach:
1. Check linked issue and test contents, determine new target directory
2. Move / rename tests to reflect purpose.
3. Add issue link / comments in separate commit.
4. Rebless if necessary and remove obsolete stderr.
r? @Kivooeo
begin `tests/ui/structs-enums` cleanup
Nearly all tests in this directory are heavily outdated, poorly formatted and have a lot of duplication. This PR is the first of a planned series of PRs to combinine this, `ui/structs` and `ui/enum` into a better structure (`ui/adt` maybe?).
some `tests/ui/macros` cleanup
Move most tests that do not run any code from `//@ run-pass` to `//@ check-pass` and merge the (outdated) `die-macro-*` tests into one file.
Move tests in the statics category
I have moved some tests I feel belong in the statics directory. Please review and let me know if this is the correct way. I think on the first two files I moved, i forgot to turn off rust analyzer and it probably formatted the files, will this be an issue?
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
Subtree sync for rustc_codegen_cranelift
The main highlights this time are a bunch of inline asm fixes for graviola and a Cranelift update.
r? @ghost
@rustbot label +A-codegen +A-cranelift +T-compiler +subtree-sync
Make PinCoerceUnsized require Deref
Also, delete impls on non-Deref types.
Pin doesn't do anything useful for non-Deref types, so PinCoerceUnsized on such types makes no sense.
This is a breaking change, since stable code can observe the deleted `PinCoerceUnsized` impls by uselessly coercing between such types inside a `Pin`.
There is still some strange behavior, such as `Pin<&mut i32>` being able to coerce to `Pin<&dyn Send>`, but not being able to coerce to `Pin<&i32>`. However, I don't think it's possible to fix this.
Fixes https://github.com/rust-lang/rust/issues/145081
* Move issue-50411 to tests/ui/mir/inliner-double-elaborate
* Addded the link for the issue to inliner-double-elaborate.rs
* Fix tidy issues
* Renamed to inliner-double-elaborate.rs
On some targets such as LoongArch64 and RISCV64, the ABI requires
sign-extension for 32-bit integer arguments, so LLVM may emit the
`signext` attribute for the `%range` parameter. The existing CHECK
pattern required the argument to be exactly `i32 noundef %range`,
causing the test to fail on those targets.
Allow an optional `signext` attribute in the CHECK pattern so the test
passes consistently across architectures without affecting the intended
codegen validation.
This replaces forking separate processes and using "cut" with Bourne
shell builtin operations for "remove largest suffix pattern" and
"remove smallest prefix pattern" operations.
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.
Xiangfei Ding