Fix another ICE in `point_at_expr_source_of_inferred_type`
Types coming from method probes must only be investigated *structurally*, since they often contain escaping infer variables from generalization and autoderef. We already have a hack in this PR that erases variables from types, so just use that.
Fixes#108664
The note attached to this error is pretty bad:
```
here the type of `primes` is inferred to be `[_]`
```
But that's unrelated to the PR.
---
Side-note: This is a pretty easy to trigger beta regression, so I've nominated it. Alternatively, I'm slightly inclined to remove this code altogether until it can be reformulated to be more accurate and less ICEy.
diagnostics: remove inconsistent English article "this" from E0107
Consider [`tests/ui/const-generics/generic_const_exprs/issue-102768.stderr`][issue-102768.stderr], the error message where it gives additional notes about where the associated type is defined, and how the dead code lint doesn't have an article, like in [`tests/ui/lint/dead-code/issue-85255.stderr`][issue-85255.stderr]. They don't have articles, so it seems unnecessary to have one here.
[issue-102768.stderr]: 07c993eba8/tests/ui/const-generics/generic_const_exprs/issue-102768.stderr
[issue-85255.stderr]: 07c993eba8/tests/ui/lint/dead-code/issue-85255.stderr
Add test for bad cast with deferred projection equality
1. Unification during coercion (`Coerce::unify`) needs to consider deferred projection obligations (at least pass over them with `predicate_may_hold` or something, to disqualify any totally wrong unifications) -- otherwise, we'll shallowly consider `<u8 as Add>::Output` and `char` as coercible during `FnCtxt::try_coerce`, which will fail later when the nested obligations are registered and processed.
2. Cast checking needs to be able to structurally normalize types so it sees `u8` instead of `<u8 as Add>::Output`. Otherwise it'll always consider the latter as part of a non-primitive cast. Currently `FnCtxt::normalize` doesn't do anything useful here, interestingly.
I tried looking into both of these and it's not immediately clear where to refactor existing typeck code to fix this (at least the latter), but I'm gonna commit a test for it at least so we don't forget. This is one of the issues that's keeping us from building larger projects.
implement const iterator using `rustc_do_not_const_check`
Previous experiment: #102225.
Explanation: rather than making all default methods work under `const` all at once, this uses `rustc_do_not_const_check` as a workaround to "trick" the compiler to not run any checks on those other default methods. Any const implementations are only required to implement the `next` method. Any actual calls to the trait methods other than `next` will either error in compile time (at CTFE runs), or run the methods correctly if they do not have any non-const operations. This is extremely easy to maintain, remove, or improve.
Consider `tests/ui/const-generics/generic_const_exprs/issue-102768.stderr`,
the error message where it gives additional notes about where the associated
type is defined, and how the dead code lint doesn't have an article,
like in `tests/ui/lint/dead-code/issue-85255.stderr`. They don't have
articles, so it seems unnecessary to have one here.
Ban associated type bounds in bad positions
We should not try to lower associated type bounds into TAITs in positions where `impl Trait` is not allowed (except for in `where` clauses, like `where T: Trait<Assoc: Bound>`).
This is achieved by using the same `rustc_ast_lowering` machinery as impl-trait does to characterize positions as universal/existential/disallowed.
Fixes#106077
Split out the first commit into #108066, since it's not really related.
Considering the following code
```rust
fn foo() -> u8 {
async fn async_fn() -> u8 { 22 }
async_fn()
}
fn main() {}
```
the error generated before this commit from the compiler is
```
➜ rust git:(macros/async_fn_suggestion) ✗ rustc test.rs --edition 2021
error[E0308]: mismatched types
--> test.rs:4:5
|
1 | fn foo() -> u8 {
| -- expected `u8` because of return type
...
4 | async_fn()
| ^^^^^^^^^^ expected `u8`, found opaque type
|
= note: expected type `u8`
found opaque type `impl Future<Output = u8>`
help: consider `await`ing on the `Future`
|
4 | async_fn().await
| ++++++
error: aborting due to previous error
```
In this case the error is nor perfect, and can confuse the user
that do not know that the opaque type is the future.
So this commit will propose (and conclude the work start in
https://github.com/rust-lang/rust/issues/80658)
to change the string `opaque type` to `future` when applicable
and also remove the Expected vs Received note by adding a more
specific one regarding the async function that return a future type.
So the new error emitted by the compiler is
```
error[E0308]: mismatched types
--> test.rs:4:5
|
1 | fn foo() -> u8 {
| -- expected `u8` because of return type
...
4 | async_fn()
| ^^^^^^^^^^ expected `u8`, found future
|
note: calling an async function returns a future
--> test.rs:4:5
|
4 | async_fn()
| ^^^^^^^^^^
help: consider `await`ing on the `Future`
|
4 | async_fn().await
| ++++++
error: aborting due to previous error
```
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Improve unexpected close and mismatch delimiter hint in TokenTreesReader
Fixes#103882Fixes#68987Fixes#69259
The inner indentation mismatching will be covered by outer block, the new added function `report_error_prone_delim_block` will find out the error prone candidates for reporting.
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.
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.
