Rollup of 8 pull requests
Successful merges:
- #110153 (Fix typos in compiler)
- #110165 (rustdoc: use CSS `overscroll-behavior` instead of JavaScript)
- #110175 (Symbol cleanups)
- #110203 (Remove `..` from return type notation)
- #110205 (rustdoc: make settings radio and checks thicker, less contrast)
- #110222 (Improve the error message when forwarding a matched fragment to another macro)
- #110237 (Split out a separate feature gate for impl trait in associated types)
- #110241 (tidy: Issue an error when UI test limits are too high)
Failed merges:
- #110218 (Remove `ToRegionVid`)
r? `@ghost`
`@rustbot` modify labels: rollup
Split out a separate feature gate for impl trait in associated types
in https://github.com/rust-lang/rust/issues/107645 it was decided that we'll take a new route for type alias impl trait. The exact route isn't clear yet, so while I'm working on implementing some of these proposed changes (e.g. in https://github.com/rust-lang/rust/pull/110010) to be able to experiment with them, I will also work on stabilizing another sugar version first: impl trait in associated types. Similarly I'll look into creating feature gates for impl trait in const/static types.
This PR does nothing but split the feature gate, so that you need to enable a different feature gate for
```rust
impl Trait for Type {
type Assoc = impl SomeTrait;
}
```
than what you need for `type Foo = impl SomeTrait;`
Improve the error message when forwarding a matched fragment to another macro
Adds a link to [Forwarding a matched fragment](https://doc.rust-lang.org/nightly/reference/macros-by-example.html#forwarding-a-matched-fragment) section of the Rust Reference, and suggests a possible fix (using `:tt` instead in the macro definition).
Also removes typos from the original message, it should be `:lifetime` instead of `$lifetime`.
## Motivation
When trying to write a macro which uses a literal in the matcher from the outer macro, like the following one, using a fragment specified that isn't one of `:ident`, `:lifetime`, or `:tt` currently results in a hard to understand message.
```rs
macro_rules! make_t_for_all_tokens {
($($name:literal as $variant:expr,)*) => {
macro_rules! t {
$(
($name) => {
$variant
};
)*
}
};
}
make_t_for_all_tokens! {
"fn" as Token::Fn,
"return" as Token::Return,
"let" as Token::Let,
}
// This creates
//
// macro_rules! t {
// ("fn") => {
// Token::Fn
// };
// ("return") => {
// Token::Return
// };
// ("let") => {
// Token::Let
// };
// }
t!["fn"];
```
### Before
```
error: no rules expected the token `"fn"`
--> src/main.rs:103:10
|
32 | macro_rules! t {
| -------------- when calling this macro
...
103 | t!["fn"];
| ^^^^ no rules expected this token in macro call
|
note: while trying to match `"fn"`
--> src/main.rs:34:6
|
34 | ($name) => {
| ^^^^^
...
58 | / make_t_for_all_tokens! {
59 | | "fn" as Token::Fn,
60 | | "return" as Token::Return,
61 | | "let" as Token::Let,
62 | | }
| |_- in this macro invocation
= note: captured metavariables except for `$tt`, `$ident` and `$lifetime` cannot be compared to other tokens
= note: this error originates in the macro `make_t_for_all_tokens` (in Nightly builds, run with -Z macro-backtrace for more info)
```
### After
```
error: no rules expected the token `"fn"`
--> src/main.rs:103:10
|
32 | macro_rules! t {
| -------------- when calling this macro
...
103 | t!["fn"];
| ^^^^ no rules expected this token in macro call
|
note: while trying to match `"fn"`
--> src/main.rs:34:6
|
34 | ($name) => {
| ^^^^^
...
58 | / make_t_for_all_tokens! {
59 | | "fn" as Token::Fn,
60 | | "return" as Token::Return,
61 | | "let" as Token::Let,
62 | | }
| |_- in this macro invocation
= note: captured metavariables except for `:tt`, `:ident` and `:lifetime` cannot be compared to other tokens
= note: see https://doc.rust-lang.org/nightly/reference/macros-by-example.html#forwarding-a-matched-fragment for more information
= help: try using `:tt` instead in the macro definition
= note: this error originates in the macro `make_t_for_all_tokens` (in Nightly builds, run with -Z macro-backtrace for more info)
```
## Unresolved questions
- Preferrably the suggestion should be attached to the `$name:literal` part of the outer macro, instead of being in the notes section at the end. But I'm not familiar with how the compiler works at all, and I have no idea how to approach this kind of solution.
- `@Nilstrieb` raised a question that the suggestion of adding `:tt` isn't accurate when there's more than `tt` being matched, for example when the input is an `item`.
Remove `..` from return type notation
`@nikomatsakis` and I decided that using `..` in the return-type notation syntax is probably overkill.
r? `@eholk` since you reviewed the last one
Since this is piggybacking now totally off of a pre-existing syntax (parenthesized generics), let me know if you need any explanation of the logic here, since it's a bit more complicated now.
Fix transmute intrinsic mir validation ICE
I stumbled across this at work, the minimal reproducer is included as a test which ICEs before this change.
I'm not 100% sure this is the right fix, but it matches what we do in `mir_assign_valid_types` so seems reasonable at least.
fixes#110151
r? `@lcnr` since they've been keeping the relevant logic correct, cc `@scottmcm`
Adds a link to the relevant part of The Rust Reference in the eror
message, and suggests a possible fix (replacing the fragment specifier
with :tt in the macro definition).
Fixes typos in the original message.
Signed-off-by: Lena Milizé <me@lvmn.org>
Split implied and super predicate queries, then allow elaborator to filter only supertraits
Split the `super_predicates_of` query into a new `implied_predicates_of` query. The former now only returns the *real* supertraits of a trait alias, and the latter now returns the implied predicates (which include all of the `where` clauses of the trait alias). The behavior of these queries is identical for regular traits.
Now that the two queries are split, we can add a new filter method to the elaborator, `filter_only_self()`, which can be used in instances that we need only the *supertrait* predicates, such as during the elaboration used in closure signature deduction. This toggles the usage of `super_predicates_of` instead of `implied_predicates_of` during elaboration of a trait predicate.
This supersedes #104745, and fixes the four independent bugs identified in that PR.
Fixes#104719Fixes#106238Fixes#110023Fixes#109514
r? types
Support safe transmute in new solver
Basically copies the same implementation as the old solver, but instead of looking for param types, we look for type or const placeholders.
Rename tests/ui/unique to tests/ui/box/unit
fixes https://github.com/rust-lang/rust/issues/109878
Since tests/ui/box already exists, I have temporarily named it boxed-box, but if another name sounds better, please let me know.
Initial support for loongarch64-unknown-linux-gnu
Hi, We hope to add a new port in rust for LoongArch.
LoongArch intro
LoongArch is a RISC style ISA which is independently designed by Loongson
Technology in China. It is divided into two versions, the 32-bit version (LA32)
and the 64-bit version (LA64). LA64 applications have application-level
backward binary compatibility with LA32 applications. LoongArch is composed of
a basic part (Loongson Base) and an expanded part. The expansion part includes
Loongson Binary Translation (LBT), Loongson VirtualiZation (LVZ), Loongson SIMD
EXtension (LSX) and Loongson Advanced SIMD EXtension(LASX).
Currently the LA464 processor core supports LoongArch ISA and the Loongson
3A5000 processor integrates 4 64-bit LA464 cores. LA464 is a four-issue 64-bit
high-performance processor core. It can be used as a single core for high-end
embedded and desktop applications, or as a basic processor core to form an
on-chip multi-core system for server and high-performance machine applications.
Documentations:
ISA:
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html
ABI:
https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
More docs can be found at:
https://loongson.github.io/LoongArch-Documentation/README-EN.html
Since last year, we have locally adapted two versions of rust, rust1.41 and rust1.57, and completed the test locally.
I'm not sure if I'm submitting all the patches at once, so I split up the patches and here's one of the commits
Migrate most of `rustc_builtin_macros` to diagnostic impls
cc #100717
This is a couple of days work, but I decided to stop for now before the PR becomes too big. There's around 50 unresolved failures when `rustc::untranslatable_diagnostic` is denied, which I'll finish addressing once this PR goes thtough
A couple of outputs have changed, but in all instances I think the changes are an improvement/are more consistent with other diagnostics (although I'm happy to revert any which seem worse)
rustc_metadata: Filter encoded data more aggressively using `DefKind`
I focused on data that contains spans, because spans are expensive to encode/decode/hash, but also touched `should_encode_visibility` too.
One incorrect use of impl visibility in diagnostics is also replaced with trait visibility.
Rollup of 8 pull requests
Successful merges:
- #109527 (Set up standard library path substitution in rust-gdb and gdbgui)
- #109752 (Stall auto trait assembly in new solver for int/float vars)
- #109860 (Add support for RISC-V relax target feature)
- #109923 (Update `error [E0449]: unnecessary visibility qualifier` to be more clear)
- #110070 (The `wrapping_neg` example for unsigned types shouldn't use `i8`)
- #110146 (fix(doc): do not parse inline when output is json for external crate)
- #110147 (Add regression test for #104916)
- #110149 (Update books)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add regression test for #104916Closes#104916
I haven't tested if it still passes with debug assertions enabled so it'd be better to wait for CI to be green.
r? compiler-errors
Update `error [E0449]: unnecessary visibility qualifier` to be more clear
This updates the error message `error[E0449]: unnecessary visibility qualifier` by clearly indicating that visibility qualifiers already inherit their visibility from a parent item. The error message previously implied that the qualifiers were permitted, which is not the case anymore.
Resolves#109822.
Add suggestion to remove `derive()` if invoked macro is non-derive
Adds to the existing `expected derive macro, found {}` error message:
```
help: remove the surrounding "derive()":
--> $DIR/macro-path-prelude-fail-4.rs:1:3
|
LL | #[derive(inline)]
| ^^^^^^^ ^
```
This suggestion will either fix the issue, in the case that the macro was valid, or provide a better error message if not
Not ready for merge yet, as the highlighted span is only valid for trivial formatting. Is there a nice way to get the parent span of the macro path within `smart_resolve_macro_path`?
Closes#109589
Migrate remainder of rustc_ty_utils to `SessionDiagnostic`
This moves the remaining errors in `rust_ty_utils` to `SessionsDiagnostic`.
r? ``@davidtwco``
Instantiate instead of erasing binder when probing param methods
Fixes#108836
There is a really old comment saying that a `WhereClauseCandidate` probe candidate "should not contain any inference variables", but I'm not really confident that that comment applies anymore. In contrast, other candidates that we assemble during method probe contain inference variables in their substitutions (e.g. `InherentImplCandidate`)...
Since this change is made only to support a nightly feature, I'm happy to gate the new behavior behind this feature flag or discuss it further.
r? types
Better diagnostic when pattern matching tuple structs
Fixes#108284
When trying to pattern match a tuple struct we might get a flawed error message if there are missing fields. E.g.
```
let x = Foo(100, 200);
if let Foo { 0: bar } = x { ... }
```
Produces this error:
```
error[E0769]: tuple variant `Foo` written as struct variant
--> hello.rs:5:12
|
5 | if let Foo { 0: foo } = x {
| ^^^^^^^^^^^^^^
|
help: use the tuple variant pattern syntax instead
|
5 | if let Foo(_, _) = x {
| ~~~~~~
```
Which doesn't highlight that we can still use the struct syntax but we need to fill missing fields. This pr changes this error to:
```
error[E0027]: pattern does not mention field `1`
--> hello.rs:5:12
|
5 | if let Foo { 0: foo } = x {
| ^^^^^^^^^^^^^^ missing field `1`
|
help: include the missing field in the pattern
|
5 | if let Foo { 0: foo, 1: _ } = x {
| ~~~~~~~~
help: if you don't care about this missing field, you can explicitly ignore it
|
5 | if let Foo { 0: foo, .. } = x {
| ~~~~~~
```
Suggest defining const parameter when appropriate
Helps a bit with #91119.
Following #105523's lead, I use placeholder `/* Type */` instead of `_` in the suggestion.
It should be easier for newcomers to parse.
`@rustbot` label A-diagnostics
r? diagnostics
Enforce that `PointerLike` requires a pointer-like ABI
At least temporarily, let's ban coercing things that are pointer-sized and pointer-aligned but *not* `Abi::Scalar(..)` into `dyn*`. See: https://github.com/rust-lang/rust/pull/104694#discussion_r1142522073
This can be lifted in the future if we decie that we *want* to be able to coerce something `repr(C)` into a `dyn*`, but we'll have to figure out what to do with Miri and codegen...
r? compiler
