dont randomly use `_` to print out const generic arguments
const generics seem to get printed out as `_` for no reason a lot of the time, as someone who spends a lot of time with const generics this has gotten ✨ very annoying ✨. Latest example would be #106423 where the ICE messaged formatted a `ty::Const` containing no infer vars, as `_`.
For some reason printing of the const argument on arrays was custom instead of using the existing logic for printing `ty::Const`. Additionally the existing logic for printing `ty::Const` would print out `_` for anon consts that are in a separate crate leading to weird diagnostics (see second commit). There ought to be less cases of consts randomly getting printed as `_` hiding valuable info now.
Add 'static lifetime suggestion when GAT implied 'static requirement from HRTB
Fix for issue #105507
The problem:
When generic associated types (GATs) are from higher-ranked trait bounds (HRTB), they are implied 'static requirement (see
[Implied 'static requirement from higher-ranked trait bounds](https://blog.rust-lang.org/2022/10/28/gats-stabilization.html#implied-static-requirement-from-higher-ranked-trait-bounds) for more details). If the user did not explicitly specify the `'static` lifetime when using the GAT, the current error message will only point out the type `does not live long enough` where the type is used, but not where the GAT is specified and how to fix the problem.
The solution:
Add notes at the span where the problematic GATs are specified and suggestions of how to fix the problem by adding `'static` lifetime at the right spans.
Constify `TypeId` ordering impls
Tracking issue: #101871
Adding const ordering to `TypeId` allows rtti crates to optimize some casting scenarios (without transmuting to `u64`). This would also prevent these crates from breaking if the underlying type is changed from `u64` to something different.
Feature gate: `#![feature(const_cmp_type_id)]`
fix: don't emit `E0711` if `staged_api` not enabled
Fixes#106589
Simple fix, added UI test.
As an aside, it seems a lot of features are susceptible to this, `E0711` stands out to me because it's perma-unstable and we are effectively exposing an implementation detail.
make error emitted on `impl &Trait` nicer
Fixes#106694
Turned out to be simpler than I thought, also added UI test.
Before: ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9bda53271ef3a8886793cf427b8cea91))
```text
error: expected one of `:`, ``@`,` or `|`, found `)`
--> src/main.rs:2:22
|
2 | fn foo(_: impl &Trait) {}
| ^ expected one of `:`, ``@`,` or `|`
|
= note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: if this is a parameter name, give it a type
|
2 | fn foo(_: impl Trait: &TypeName) {}
| ~~~~~~~~~~~~~~~~
help: if this is a type, explicitly ignore the parameter name
|
2 | fn foo(_: impl _: &Trait) {}
| ++
error: expected one of `!`, `(`, `)`, `,`, `?`, `for`, `~`, lifetime, or path, found `&`
--> src/main.rs:2:16
|
2 | fn foo(_: impl &Trait) {}
| -^ expected one of 9 possible tokens
| |
| help: missing `,`
error: expected one of `!`, `(`, `,`, `=`, `>`, `?`, `for`, `~`, lifetime, or path, found `&`
--> src/main.rs:3:11
|
3 | fn bar<T: &Trait>(_: T) {}
| ^ expected one of 10 possible tokens
```
After:
```text
error: expected a trait, found type
--> <anon>:2:16
|
2 | fn foo(_: impl &Trait) {}
| -^^^^^
| |
| help: consider removing the indirection
error: expected a trait, found type
--> <anon>:3:11
|
3 | fn bar<T: &Trait>(_: T) {}
| -^^^^^
| |
| help: consider removing the indirection
```
suggestion for attempted integer identifier in patterns
Fixes#106552
Implemented a suggestion on `E0005` that occurs when no bindings are present and the pattern is a literal integer.
Heuristically undo path prefix mappings.
Because the compiler produces better diagnostics if it can find the source of (potentially remapped) dependencies.
The new test fails without the other changes in this PR. Let me know if you have better suggestions for the test directory. I moved the existing remapping test to be in the same location as the new one.
Some more context: I'm exploring running UI tests with remapped paths by default in https://github.com/rust-lang/rust/pull/105924 and this was one of the issues discovered.
This may also be useful in the context of https://github.com/rust-lang/rfcs/pull/3127 ("New rustc and Cargo options to allow path sanitisation by default").
Emit only one nbsp error per file
Fixes#106101.
See https://github.com/rust-lang/rust/issues/106098 for an explanation of how someone would end up with a large number of these nbsp characters in their source code, which is why I think rustc needs to handle this specific case in a friendlier way.
suggest `is_empty` for collections when casting to `bool`
Fixes#106883
Matches on slices, `String` and `str`. It would be nice to do this with something like `Deref<Target=str>` as well, but AFAIK it's not possible in this part of the compiler.
Consolidate two almost duplicated fn info extraction routines
Moves `extract_callable_info` up to trait selection, because it was being (almost) duplicated fully there for similar diagnostic purposes. This also generalizes the diagnostics we can give slightly (see UI test).
Suggestion for type mismatch when we need a u8 but the programmer wrote a char literal
Today Rust just points out that we have a char and we need a u8, but if I wrote 'A' then I could fix this by just writing b'A' instead. This code should detect the case where we're about to report a type mismatch of this kind, and the programmer wrote a char literal, and the char they wrote is ASCII, so therefore just prefixing b to make a byte literal will do what they meant.
I have definitely written this mistake more than once, it's not difficult to figure out what to do, but the compiler might as well tell us anyway.
I provided a test with two simple examples where the suggestion is appropriate, and one where it is not because the char literal is not ASCII, showing that the suggestion is only triggered in the former cases.
I have contributed only a small typo doc fix before, so this is my first substantive rustc change.
