Skip to content
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

Merged
merged 3 commits into from
Nov 11, 2020

Conversation

guswynn
Copy link
Contributor

@guswynn guswynn commented Sep 15, 2020

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() vs fn f() -> (), can you tell those apart in the hir?)

R? @tmandry

@rustbot modify labels +A-diagnostics +T-compiler

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 15, 2020
@rustbot rustbot added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 15, 2020
@jyn514 jyn514 added the A-async-await Area: Async & Await label Sep 15, 2020
@guswynn
Copy link
Contributor Author

guswynn commented Sep 15, 2020

ci failed but I want to make sure Im on the right path first

Comment on lines 4 to 15
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]]) {
| ^
Copy link
Contributor

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
Copy link
Member

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.

Copy link
Contributor Author

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!

@camelid camelid added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 16, 2020
@camelid
Copy link
Member

camelid commented Oct 16, 2020

@guswynn Could you address the review comments?

@guswynn
Copy link
Contributor Author

guswynn commented Oct 17, 2020 via email

@guswynn guswynn force-pushed the async_return branch 2 times, most recently from 31a944d to 3d66d3b Compare October 17, 2020 22:24
@guswynn
Copy link
Contributor Author

guswynn commented Oct 17, 2020

Updated to the comments.
I have 2 questions

  1. @tmandry mentioned in Make it more clear what an about async fn's returns when referring to what it returns #76765 (comment) that the message this works off may be unclear in some cases, should that a different issue?
  2. wording-wise, is it ok in rust-lang to prepend a span_label msg with "note: "?

@JohnCSimon
Copy link
Member

ping from triage - @guswynn can you mark the 'change requested' comments from camelid as addressed? is this PR ready for review?

@guswynn
Copy link
Contributor Author

guswynn commented Nov 3, 2020

@JohnCSimon I believe I marked the comment as resolved, I am.not sure how to clear the request changes.
The pr is ready to review!

@camelid camelid added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 3, 2020
@@ -85,6 +85,60 @@ impl<'a, 'tcx> NiceRegionError<'a, 'tcx> {
})
}

pub(super) fn future_return_type(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc #78755

@tmandry
Copy link
Member

tmandry commented Nov 5, 2020

Sorry, this fell off the radar. I think it is fine to merge. Thanks!!

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Nov 5, 2020

📌 Commit 20e032e has been approved by tmandry

@bors bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Nov 5, 2020
@camelid
Copy link
Member

camelid commented Nov 5, 2020

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`.

@guswynn
Copy link
Contributor Author

guswynn commented Nov 5, 2020

I'll try to fix the rebase in the next few days when I find time

@guswynn
Copy link
Contributor Author

guswynn commented Nov 5, 2020

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`.

Looks like the test I ADDED no longer triggers the codepath, so this may be more involved to figure out

@JohnTitor
Copy link
Member

@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
Copy link
Contributor

estebank commented Nov 6, 2020

./x.py test src/test/ui --stage 1 --keep-stage 1 --bless --compare-mode=nll

@guswynn
Copy link
Contributor Author

guswynn commented Nov 8, 2020

@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?

@estebank
Copy link
Contributor

estebank commented Nov 9, 2020

We are saying that in CI tests check for nll enabled output, but locally by default it doesn't.

Running ./x.py test src/test/ui --stage 1 --keep-stage 1 --bless --compare-mode=nll will bless the nll output files and make it pass CI.

@guswynn
Copy link
Contributor Author

guswynn commented Nov 10, 2020

@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?)

@tmandry
Copy link
Member

tmandry commented Nov 10, 2020

@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.

@tmandry
Copy link
Member

tmandry commented Nov 10, 2020

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Nov 10, 2020

📌 Commit 6be4847 has been approved by tmandry

@bors
Copy link
Contributor

bors commented Nov 10, 2020

🌲 The tree is currently closed for pull requests below priority 100, this pull request will be tested once the tree is reopened

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 10, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 11, 2020
…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
@bors bors merged commit 9596e34 into rust-lang:master Nov 11, 2020
@rustbot rustbot added this to the 1.49.0 milestone Nov 11, 2020
@guswynn guswynn deleted the async_return branch February 19, 2021 21:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-async-await Area: Async & Await A-diagnostics Area: Messages for errors, warnings, and lints S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

10 participants