rustc_expand: improve diagnostics for non-repeatable metavars in repetition
Enhance `NoSyntaxVarsExprRepeat` by suggesting similarly named metavariables, distinguishing repeatable vs non-repeatable bindings, and listing available repeatable variables when no match exists.
Simplify the canonical enum clone branches to a copy statement
I have overhauled MatchBranchSimplification in this PR. This pass tries to unify statements one by one, which is more readable and extensible.
This PR also unifies the following pattern that is mostly generated by GVN into one basic block that contains the copy statement:
```rust
match a {
Foo::A(_) => *a,
Foo::B => Foo::B
}
```
Fixes https://github.com/rust-lang/rust/issues/128081.
Avoid delayed-bug ICE for malformed diagnostic attrs
Fixesrust-lang/rust#152744
Skip suggestions in `expected_lit` when parsing with `Recovery::Forbidden`, since this may later cancel `InvalidMetaItem`. This avoids creating delayed bugs that can be promoted to ICE.
Do no add -no-pie on Windows
Windows binaries are always position independent and Clang warns when trying to enable or disable that:
```
❯ clang hello.c -pie
clang: warning: argument unused during compilation: '-pie' [-Wunused-command-line-argument]
❯ clang hello.c -no-pie
clang: warning: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument]
```
https://github.com/rust-lang/rust/pull/149937 will turn these warnings into build errors:
```
❯ cargo rustc -- -D linker-messages
Compiling hello v0.1.0 (E:\tmp\hello)
error: linker stderr: x86_64-w64-mingw32-clang: argument unused during compilation: '-nolibc' [-Wunused-command-line-argument]␍
x86_64-w64-mingw32-clang: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument]␍
|
= note: requested on the command line with `-D linker-messages`
error: could not compile `hello` (bin "hello") due to 1 previous error
```
Reflection TypeKind::FnPtr
This is for https://github.com/rust-lang/rust/issues/146922.
Const-eval currently lacks full support for function pointer (fn) types. We should implement handling of FnPtr TypeKind, covering safe and unsafe functions, Rust and custom ABIs, input and output types, higher-ranked lifetimes, and variadic functions.
Fix ICE in transmutability error reporting when type aliases are normalized
Fixesrust-lang/rust#151462
Transmutability error reporting hit an ICE when type aliases were normalized for diagnostics. For example, when type
`JustUnit = ()` normalizes to `()`, the check passes unexpectedly even though the original check with `JustUnit` failed.
Fixed by adding a retry in the `Answer::Yes` arm that checks with the root obligation's types before panicking. The retry only occurs when the root obligation differs and is a Transmute trait predicate.
Also added a test that reproduces the original ICE.
- Implement handling of FnPtr TypeKind in const-eval, including:
- Unsafety flag (safe vs unsafe fn)
- ABI variants (Rust, Named(C), Named(custom))
- Input and output types
- Variadic function pointers
- Add const-eval tests covering:
- Basic Rust fn() pointers
- Unsafe fn() pointers
- Extern C and custom ABI pointers
- Functions with multiple inputs and output types
- Variadic functions
- Use const TypeId checks to verify correctness of inputs, outputs, and payloads
Enhance `NoSyntaxVarsExprRepeat` by suggesting similarly named
metavariables, distinguishing repeatable vs non-repeatable bindings,
and listing available repeatable variables when no match exists.
Co-authored-by: Esteban Küber <esteban@kuber.com.ar>
Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com>
Windows binaries are always position independent
and Clang warns when trying to enable or disable
that:
```
❯ clang hello.c -pie
clang: warning: argument unused during compilation: '-pie' [-Wunused-command-line-argument]
❯ clang hello.c -no-pie
clang: warning: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument]
```
Miri: recursive validity: also recurse into Boxes
Now that https://github.com/rust-lang/rust/issues/97270 is fixed, the recursive validity mode for Miri can recuse into Boxes without exploding everywhere.
make `rustc_allow_const_fn_unstable` an actual `rustc_attrs` attribute
It is already named like one, but used to have its own feature gate, which this PR now removes in favor of just using `#![feature(rustc_attrs)]`.
Most of the diff is just the line number changes in `malformed-attrs.stderr`.
Fix invalid `mut T` suggestion for `&mut T` in missing lifetime error
close: rust-lang/rust#150077
When suggesting to return an owned value instead of a borrowed one, the diagnostic was only removing `&` instead of `&mut `, resulting in invalid syntax like `mut T`. This PR fixes the span calculation to properly cover the entire `&mut ` prefix.
remove the explicit error for old `rental` versions
This was converted to a hard error 20 months ago (in rust-lang/rust#125596). This seems like enough time for anyone still using it to notice, so remove the note entirely now.
In comparison, the explicit note for the more impactful `time` breakage was already removed after 6 months (rust-lang/rust#129343).
Closesrust-lang/rust#73933.
Closesrust-lang/rust#83125.
r? @petrochenkov
Rename dep node "fingerprints" to distinguish key and value hashes
In the query system's dependency graph, each node is associated with two *fingerprints*: one that is typically a hash of the query key, and one that is typically a hash of the query's return value when called with that key.
Unfortunately, many identifiers and comments fail to clearly distinguish between these two kinds of fingerprint, which have very different roles in dependency tracking. This is a frequent source of confusion.
This PR therefore tries to establish a clear distinction between:
- **Key fingerprints** that help to uniquely identify a node (along with its `DepKind`), and are typically a hash of the query key
- **Value fingerprints** that help to determine whether a node can be marked green (despite having red dependencies), and are typically a hash of the query value
There should be no change to compiler behaviour.
r? nnethercote (or compiler)
tail calls: fix copying non-scalar arguments to callee
Alternative to https://github.com/rust-lang/rust/pull/144933: when invoking a tail call with a non-scalar argument, we need to delay freeing the caller's local variables until after the callee is initialized, so that we can copy things from the caller to the callee.
Fixes https://github.com/rust-lang/rust/issues/144820... but as the FIXMEs in the code show, it's not clear to me whether these are the right semantics.
r? @WaffleLapkin
Unify wording of resolve error
Remove "failed to resolve" from the main error message and use the same format we use in other resolution errors "cannot find `name`":
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
The intent behind this is to end up with all resolve errors eventually be on the form of
```
error[ECODE]: cannot find `{NAME}` in {SCOPE}
--> $DIR/file.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ {SPECIFIC LABEL}
```
A category of errors that is interest are those that involve keywords. For example:
```
error[E0433]: cannot find `Self` in this scope
--> $DIR/issue-97194.rs:2:35
|
LL | fn bget(&self, index: [usize; Self::DIM]) -> bool {
| ^^^^ `Self` is only available in impls, traits, and type definitions
```
and
```
error[E0433]: cannot find `super` in this scope
--> $DIR/keyword-super.rs:2:9
|
LL | let super: isize;
| ^^^^^ there are too many leading `super` keywords
```
For these the label provides the actual help, while the message is less informative beyond telling you "couldn't find `name`".
This is an off-shoot of https://github.com/rust-lang/rust/pull/126810 and https://github.com/rust-lang/rust/pull/128086, a subset of the intended changes there with review comments applied.
r? @petrochenkov
bors