-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bad diagnostic for Send bound on Future coming from async fn in foreign crate #78543
Comments
Some more information:
I've reduced the |
Current status:
Those two result in materialized reduced and pgwire reduced (but will probably be minimized further). I feel/hope |
Alrighty, we're finally down to a manageable size, 100 lines or so in 2 crates
They could for sure be reduced further (if someone wants to have fun), but doing so also significantly reduces the futures' obligation chain and the problematic amount of diagnostics described in the blog post and this issue. |
I looked into this briefly today, as per @estebank's Twitter thread, this line seems to the culprit: rust/compiler/rustc_trait_selection/src/traits/error_reporting/suggestions.rs Lines 1371 to 1374 in 5d5ff84
Removing that results in an ICE because we cannot get the typeck results for the other crate - I've got to assume that adding typeck results to the cross-crate metadata would be bad for perf, but it might less bad if we just added the |
Triage: This does seem like an important fix to make and @davidtwco describes a pretty clear path to implementing it. Marking on deck for wg-async-foundations. |
@rustbot claim |
… crate Partly address rust-lang#78543 by making the error quieter. We don't have access to the `typeck` tables from foreign crates, so we used to completely skip the new code when checking foreign crates. Now, we carry on and don't provide as nice output (we don't clarify *what* is making the `Future: !Send`), but at least we no longer emit a sea of derived obligations in the output. [1]: https://blog.rust-lang.org/inside-rust/2019/10/11/AsyncAwait-Not-Send-Error-Improvements.html
…n-future, r=tmandry Use the "nice E0277 errors"[1] for `!Send` `impl Future` from foreign crate Partly address rust-lang#78543 by making the error quieter. We don't have access to the `typeck` tables from foreign crates, so we used to completely skip the new code when checking foreign crates. Now, we carry on and don't provide as nice output (we don't clarify *what* is making the `Future: !Send`), but at least we no longer emit a sea of derived obligations in the output. [1]: https://blog.rust-lang.org/inside-rust/2019/10/11/AsyncAwait-Not-Send-Error-Improvements.html r? `@tmandry`
The merged PR has output improvement. Leaving open. The outstanding work on this ticket is to add cross-crate metadata to be able to point at the same places we can in local crates. |
Getting into the development of the Rust compiler, and trying my luck with solving this issue #94493. I followed the solution laid above by @davidtwco |
…c_fn_in_foreign_crate_diag_2, r=davidtwco Improved diagnostic on failure to meet send bound on future in a foreign crate Provide a better diagnostic on failure to meet send bound on futures in a foreign crate. fixes rust-lang#78543
…c_fn_in_foreign_crate_diag_2, r=davidtwco Improved diagnostic on failure to meet send bound on future in a foreign crate Provide a better diagnostic on failure to meet send bound on futures in a foreign crate. fixes rust-lang#78543
As documented in Debugging async generator errors, when the problematic generator is in a foreign crate, we don't give the nice errors for things being kept through an
await
point. The reason for that is this early return. We need to figure out a way of performing the subsequent analysis on foreign crates.You can find some of my analysis so far in this thread.
CC @tmandry @davidtwco
A (non-minimal) reproduction branch is available at https://github.com/mjibson/materialize/tree/async-error-message.
The text was updated successfully, but these errors were encountered: