Modify primary span label for E0308
Looking at the reactions to https://hachyderm.io/`@ekuber/109622160673605438,` a lot of people seem to have trouble understanding the current output, where the primary span label on type errors talks about the specific types that diverged, but these can be deeply nested type parameters. Because of that we could see "expected i32, found u32" in the label while the note said "expected Vec<i32>, found Vec<u32>". This understandably confuses people. I believe that once people learn to read these errors it starts to make more sense, but this PR changes the output to be more in line with what people might expect, without sacrificing terseness.
Fix#68220.
Skip possible where_clause_object_safety lints when checking `multiple_supertrait_upcastable`
Fix#106247
To achieve this, I lifted the `WhereClauseReferencesSelf` out from `object_safety_violations` and move it into `is_object_safe` (which is changed to a new query).
cc `@dtolnay`
r? `@compiler-errors`
Implement some more new solver candidates and fix some bugs
First, fix some bugs:
1. `IndexVec::drain_enumerated(a..b)` does not give us an iterator of index keys + items enumerated from `a..b`, but from `0..(b-a)`... That caused a bug. See first commit for the fix.
2. Implement the `_: Trait` ambiguity hack. I put it in assemble, let me know if it should live elsewhere. This is important, since we otherwise consider `_: Sized` to have no solutions, and nothing passes!
3. Swap `Ambiguity` and `Unimplemented` cases for the new solver. Sorry for accidentally swapping them 😄
4. Check GATs' own predicates during projection confirmation.
Then implement a few builtin traits:
5. Implement `PointerSized`. Pretty independent.
6. Implement `Fn` family of traits for fnptr, fndef, and closures. Closures are currently broken because `FulfillCtxt::relationships` is intentionally left unimplemented. See comment in the test.
r? ```@lcnr```
Emit a hint for bad call return types due to generic arguments
When the return type of a function call depends on the type of an argument, e.g.
```
fn foo<T>(x: T) -> T {
x
}
```
and the expected type is set due to either an explicitly typed binding, or because the call to the function is in a tail position without semicolon, the current error implies that the argument in the call has the wrong type.
This new hint highlights that the expected type doesn't match the returned type, which matches the argument type, and that that's why we're flagging the argument type.
Fixes#43608.
I encountered an instance where an `FnPtr` implemented a trait, but I was passing an `FnDef`. To
the end user, there is really no way to differentiate each of them, but it is necessary to cast
to the generic function in order to compile. It is thus useful to suggest `as` in the help note,
(even if the Fn output implements the trait).
When the return type of a function call depends on the type of an
argument, e.g.
```
fn foo<T>(x: T) -> T {
x
}
```
and the expected type is set due to either an explicitly typed
binding, or because the call to the function is in a tail position
without semicolon, the current error implies that the argument in the
call has the wrong type.
This new hint highlights that the expected type doesn't match the
returned type, which matches the argument type, and that that's why
we're flagging the argument type.
Fixes#43608.
Prefer non-`[type error]` candidates during selection
Fixes#102130Fixes#106351
r? types
note: Alternatively we could filter out error where-clauses during param-env construction? But we still need to filter out impls with errors during `match_impl`, I think.
