Revert "Improve heuristics whether `format_args` string is a source literal"
This reverts commit e6c02aad9345925cfed74f86b414c4d0715d381b (from #106195).
Keeps the code improvements from the PR and the test (as a known-bug).
Works around #106408 while a proper fix is discussed more thoroughly in #106505, as proposed by `@tmandry.`
Reopens#106191
r? compiler-errors
Do not filter substs in `remap_generic_params_to_declaration_params`.
The relevant filtering should have been performed by borrowck.
Fixes https://github.com/rust-lang/rust/issues/105826
r? types
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.
