-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Make it more clear what an about async fn's returns when referring to what it returns #76765
Conversation
8190bd7
to
9f2f83b
Compare
ci failed but I want to make sure Im on the right path first |
d54aad9
to
10cc864
Compare
compiler/rustc_infer/src/infer/error_reporting/nice_region_error/different_lifetimes.rs
Outdated
Show resolved
Hide resolved
LL | async fn fut(bufs: &mut [&mut [u8]]) { | ||
| --------- - | ||
| | | ||
| this parameter and the returned future are declared with different lifetimes... | ||
LL | ListFut(bufs).await | ||
| ^^^^ ...but data from `bufs` is held across an await point here | ||
| | ||
note: `async fn`s return an `impl Future<Output={return type}` | ||
--> $DIR/issue-76547.rs:19:38 | ||
| | ||
LL | async fn fut(bufs: &mut [&mut [u8]]) { | ||
| ^ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'll need to handle this case when including the return type snippet to be impl Future<Output = ()>
for this case.
@@ -4,8 +4,14 @@ error[E0623]: lifetime mismatch | |||
LL | async fn async_ret_impl_trait1<'a, 'b>(a: &'a u8, b: &'b u8) -> impl Trait<'a> { | |||
| ------ ^^^^^^^^^^^^^^ | |||
| | | | |||
| | ...but data from `b` is returned here | |||
| this parameter and the return type are declared with different lifetimes... | |||
| | ...but data from `b` is held across an await point here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, this wording doesn't really work if the error is in the function signature itself. I'm confused why the span is pointing here, but one way to make the diagnostic less wrong is to remove the word "here". Then we're just telling you what's happening and providing a span that might help.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good, when I find time (hopefully tomorrow) I will dig into these comments!
@guswynn Could you address the review comments? |
I'll try to get to it this weekend!
…On Thu, Oct 15, 2020, 7:32 PM Camelid ***@***.***> wrote:
@guswynn <https://github.com/guswynn> Could you address the review
comments?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#76765 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJHNDZL2TVYWNFLEGXO4NLSK6WEPANCNFSM4RN2XERA>
.
|
31a944d
to
3d66d3b
Compare
Updated to the comments.
|
...iler/rustc_infer/src/infer/error_reporting/nice_region_error/.different_lifetimes.rs.rustfmt
Outdated
Show resolved
Hide resolved
ping from triage - @guswynn can you mark the 'change requested' comments from camelid as addressed? is this PR ready for review? |
@JohnCSimon I believe I marked the comment as resolved, I am.not sure how to clear the request changes. |
@@ -85,6 +85,60 @@ impl<'a, 'tcx> NiceRegionError<'a, 'tcx> { | |||
}) | |||
} | |||
|
|||
pub(super) fn future_return_type( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc #78755
Sorry, this fell off the radar. I think it is fine to merge. Thanks!! @bors r+ rollup |
📌 Commit 20e032e has been approved by |
Here's the diff: - error[E0623]: lifetime mismatch
- --> $DIR/issue-76547.rs:20:13
+ error: lifetime may not live long enough
+ --> $DIR/issue-76547.rs:19:14
|
LL | async fn fut(bufs: &mut [&mut [u8]]) {
- | --------- -
- | | |
- | | this `async fn` implicitly returns an `impl Future<Output = ()>`
- | this parameter and the returned future are declared with different lifetimes...
- LL | ListFut(bufs).await
- | ^^^^ ...but data from `bufs` is held across an await point here
+ | ^^^^ - - let's call the lifetime of this reference `'2`
+ | | |
+ | | let's call the lifetime of this reference `'1`
+ | assignment requires that `'1` must outlive `'2`
- error[E0623]: lifetime mismatch
- --> $DIR/issue-76547.rs:34:14
+ error: lifetime may not live long enough
+ --> $DIR/issue-76547.rs:33:15
|
LL | async fn fut2(bufs: &mut [&mut [u8]]) -> i32 {
- | --------- ---
- | | |
- | | this `async fn` implicitly returns an `impl Future<Output = i32>`
- | this parameter and the returned future are declared with different lifetimes...
- LL | ListFut2(bufs).await
- | ^^^^ ...but data from `bufs` is held across an await point here
+ | ^^^^ - - let's call the lifetime of this reference `'2`
+ | | |
+ | | let's call the lifetime of this reference `'1`
+ | assignment requires that `'1` must outlive `'2`
error: aborting due to 2 previous errors
- For more information about this error, try `rustc --explain E0623`. |
I'll try to fix the rebase in the next few days when I find time |
Looks like the test I ADDED no longer triggers the codepath, so this may be more involved to figure out |
@guswynn We have a builder that enables nll compare mode so you should tweak the test like https://github.com/rust-lang/rust/pull/78268/files#diff-4e99585b86f1234b2e3f288f2e63e8dde1f23834ba26bc79e69d2aace14fd238. |
|
@estebank @JohnTitor are you saying that this has rebased onto something turning on a new nll mode? and in the test I should just turn it off? |
We are saying that in CI tests check for nll enabled output, but locally by default it doesn't. Running |
@estebank thats a fantastic command! Added the change! should I make a follow up issue to fix the message for compare-mode=nll? (I am not sure why its different, nll has been stable for ages?) |
Hm yeah, not sure either, it can't hurt to file an issue. |
Co-authored-by: Camelid <[email protected]>
@bors r+ rollup |
📌 Commit 6be4847 has been approved by |
🌲 The tree is currently closed for pull requests below priority 100, this pull request will be tested once the tree is reopened |
…as-schievink Rollup of 14 pull requests Successful merges: - rust-lang#76765 (Make it more clear what an about async fn's returns when referring to what it returns) - rust-lang#78574 (Use check-pass instead of build-pass in regions ui test suite) - rust-lang#78669 (Use check-pass instead of build-pass in some consts ui test suits) - rust-lang#78847 (Assert that a return place is not used for indexing during integration) - rust-lang#78854 (Workaround for "could not fully normalize" ICE ) - rust-lang#78875 (rustc_target: Further cleanup use of target options) - rust-lang#78887 (Add comments to explain memory usage optimization) - rust-lang#78890 (comment attribution fix) - rust-lang#78896 (Clarified description of write! macro) - rust-lang#78897 (Add missing newline to error message of the default OOM hook) - rust-lang#78898 (add regression test for rust-lang#78892) - rust-lang#78908 ((rustdoc) [src] link for types defined by macros shows invocation, not defintion) - rust-lang#78910 (Fix links to stabilized versions of some intrinsics) - rust-lang#78912 (Add macro test for min-const-generics) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
see #76547
This is likely not the ONLY place that this happens to be unclear, but we can move this fn to rustc_middle or something like that and reuse it if need be, to apply it to more diagnostics
One outstanding question I have is, if the fn returns (), should I make the message more clear (what about
fn f()
vsfn f() -> ()
, can you tell those apart in the hir?)R? @tmandry
@rustbot modify labels +A-diagnostics +T-compiler