Indicate origin of where type parameter for uninferred types
Based on #65951 (which is not merge yet), fixes#67277.
This PR improves a little the diagnostic for code like:
```
async fn foo() {
bar().await;
}
async fn bar<T>() -> () {}
```
by showing:
```
error[E0698]: type inside `async fn` body must be known in this context
--> unresolved_type_param.rs:9:5
|
9 | bar().await;
| ^^^ cannot infer type for type parameter `T` declared on the function `bar`
|
...
```
(The
```
declared on the function `bar`
```
part is new)
A small side note: `Vec` and `slice` seem to resist this change, because querying `item_name()` panics, and `get_opt_name()` returns `None`.
r? @estebank
async/await: improve not-send errors, part 2
Part of #64130. Fixes#65667.
This PR improves the errors introduced in #64895 so that they have specialized messages for `Send` and `Sync`.
r? @nikomatsakis
The reason we were invoking `builtin_deref` was to enable comparisons
when the type was `&T`. For the reasons outlined in the comment, those
comparisons failed because the regions disagreed.
rustc: allow non-empty ParamEnv's in global trait select/eval caches.
*Based on #66963*
This appears to alleviate the symptoms of #65510 locally (without fixing WF directly), and is potentially easier to validate as sound (since it's a more ad-hoc version of queries we already have).
I'm opening this PR primarily to test the effects on perf.
r? @nikomatsakis cc @rust-lang/wg-traits
From a `Vec<Ty>` to a `Vec<InferTy>`, because that's a more restrictive
type. This is a perf win because the ultra-hot function
`shallow_resolve_changed` has less pattern-matching to do.
This commit corrects the diagnostic note for `async move {}` so that
`await` is mentioned, rather than `yield`.
Signed-off-by: David Wood <david@davidtw.co>
Add `enclosing scope` parameter to `rustc_on_unimplemented`
Adds a new parameter to `#[rustc_on_unimplemented]`, `enclosing scope`, which highlights the function or closure scope with a message.
The wip part refers to adding this annotation to `Try` trait to improve ergonomics (which I don't know how to do since I change both std and librustc)
Closes#61709.
Apply proper commit from PR #63934
While working on PR #63934, I accidentally reverted to an older version
of the PR while working on a rebase. The PR was then merged, not with
the later, approved changes, but with earlier, unapproved changes.
This PR applies the changes that were *suppoesd* to be mereged in
PR #63934. All of the proper tests appear to have been merged
in PR #63934, so this PR adds no new tests
While working on PR #63934, I accidentally reverted to an older version
of the PR while working on a rebase. The PR was then merged, not with
the later, approved changes, but with earlier, unapproved changes.
This PR applies the changes that were *suppoesd* to be mereged in
PR #63934. All of the proper tests appear to have been merged
in PR #63934, so this PR adds no new tests
Fixes#66580
Issue #22750
The error reporting for E0277 (the trait `X` is not implemented for `Foo`)
now checks whether `Foo` implements a trait with the same path as `X`,
which probably means that the programmer wanted to actually use only one
version of the trait `X` instead of the two.
Suggest calling async closure when needed
When using an async closure as a value in a place that expects a future,
suggest calling the closure.
Fix#65923.
Suggest borrowing when it would satisfy an unmet trait bound
When there are multiple implementors for the same trait that is present
in an unmet binding, modify the E0277 error to refer to the parent
obligation and verify whether borrowing the argument being passed in
would satisfy the unmet bound. If it would, suggest it.
Fix#56368.
Derive TypeFoldable using a proc-macro
A new proc macro is added in librustc_macros.
It is used to derive TypeFoldable inside librustc and librustc_traits.
For now, the macro uses the `'tcx` lifetime implicitly, and does not allow for a more robust selection of the adequate lifetime.
The Clone-based TypeFoldable implementations are not migrated.
Closes#65674
