Rollup of 10 pull requests
Successful merges:
- #103478 ( Suggest fix for misplaced generic params on fn item #103366 )
- #107739 (Check for overflow in evaluate_canonical_goal)
- #108003 (Avoid ICE when the generic_span is empty)
- #108016 ("Basic usage" is redundant for there is just one example)
- #108023 (Shrink size of array benchmarks)
- #108024 (add message to update Cargo.toml when x is changed)
- #108025 (rustdoc: add more tooltips to intra-doc links)
- #108029 (s/eval_usize/eval_target_usize/ for clarity)
- #108035 (Avoid using a dead email address as the main email address)
- #108038 (Remove needless supertrait constraints from Interner projections)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove needless supertrait constraints from Interner projections
These associated types are already all constrained to implement `Ord`, so specifically requiring its supertraits `Eq`, `PartialEq` and `PartialOrd` is superfluous.
Avoid using a dead email address as the main email address
This caused highfive to welcome me as a new contributor on every PR, because it couldn't find any commits of mine.
Suggest fix for misplaced generic params on fn item #103366fixes#103366
This still has some work to go, but works for 2/3 of the initial base cases described in #1033366
simple fn:
```
error: expected identifier, found `<`
--> shreys/test_1.rs:1:3
|
1 | fn<T> id(x: T) -> T { x }
| ^ expected identifier
|
help: help: place the generic parameter list after the function name:
|
1 | fn id<T>(x: T) -> T { x }
| ~~~~
```
Complicated bounds
```
error: expected identifier, found `<`
--> spanishpear/test_2.rs:1:3
|
1 | fn<'a, B: 'a + std::ops::Add<Output = u32>> f(_x: B) { }
| ^ expected identifier
|
help: help: place the generic parameter list after the function name:
|
1 | fn f<'a, B: 'a + std::ops::Add<Output = u32>>(_x: B) { }
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Opening a draft PR for comments on approach, particularly I have the following questions:
- [x] Is it okay to be using `err.span_suggestion` over struct derives? I struggled to get the initial implementation (particularly the correct suggestion message) on struct derives, although I think given what I've learned since starting, I could attempt re-doing it with that approach.
- [x] in the case where the snippet cannot be obtained from a span, is the `help` but no suggestion okay? I think yes (also, when does this case occur?)
- [x] are there any red flags for the generalisation of this work for relevant item kinds (i.e. `struct`, `enum`, `trait`, and `union`). My basic testing indicates it does work for those types except the help tip is currently hardcoded to `after the function name` - which should change dependent on the item.
- [x] I am planning to not show the suggestion if there is already a `<` after the item identifier, (i.e. if there are already generics, as after a function name per the original issue). Any major objections?
- [x] Is the style of error okay? I wasn't sure if there was a way to make it display nicer, or if thats handled by span_suggestion
These aren't blocking questions, and I will keep working on:
- check if there is a `<` after the ident (and if so, not showing the suggestion)
- generalize the help message
- figuring out how to write/run/etc ui tests (including reading the docs for them)
- logic cleanups
fix: Search raw identifiers without prefix
When we find references/usages of a raw identifier, we should disregard `r#` prefix because there are keywords one can use without the prefix in earlier editions (see #13034; this bug is actually fallout from the PR). `name`, the text we're searching for, has already been stripped of the prefix, but the text of nodes we compare it to hasn't been.
The second commit is strictly refactoring, I can remove it if it's not much of value.
