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

Provide appropriate suggestions for some of the discussed await syntaxes #60613

Closed
estebank opened this issue May 7, 2019 · 3 comments

Comments

Projects
None yet
3 participants
@estebank
Copy link
Contributor

commented May 7, 2019

Regardless of the final syntax selected for await, given the prevalence of prefix keyword in other languages, and the possibility of thinking it is a method, the parser should support these syntaxes and error with an appropriate targeted diagnostic. Furthermore, should the field or method syntax were to be chosen, we should have reasonable behavior with explanations when accidentally using await when trying to access a field or call a similar method both inside and outside of async blocks.

@estebank

This comment has been minimized.

Copy link
Contributor Author

commented May 7, 2019

Some of the cases to have tests for:

async fn foo() {
    let _ = await bar();
}
async fn foo() {
    let _ = await? bar();
}
async fn foo() {
    let _ = await bar()?;
}
async fn foo() {
    let _ = (await bar())?;
}
async fn foo() {
    let _ = bar().await();
}
async fn foo() {
    let _ = bar().await()?;
}
async fn foo() {
    let _ = bar().await;
}
async fn foo() {
    let _ = bar().await?;
}
fn foo() {
    let _ = await bar();
}
fn foo() {
    let _ = await? bar();
}
fn foo() {
    let _ = await bar()?;
}
fn foo() {
    let _ = (await bar())?;
}
fn foo() {
    let _ = bar().await();
}
fn foo() {
    let _ = bar().await()?;
}
fn foo() {
    let _ = bar().await;
}
fn foo() {
    let _ = bar().await?;
}

And we should have structs that have both similar method and field names, including r#await.

@Centril

This comment has been minimized.

Copy link
Member

commented May 7, 2019

the parser should support these syntaxes and error with an appropriate targeted diagnostic

As long as you make sure that this doesn't stabilize the syntax (i.e. you need to account for macros) then I think this is a good idea.

@estebank

This comment has been minimized.

Copy link
Contributor Author

commented May 7, 2019

cc #60586

Centril added a commit to Centril/rust that referenced this issue May 17, 2019

Rollup merge of rust-lang#60873 - estebank:bad-await, r=Centril
Parse alternative incorrect uses of await and recover

Fix rust-lang#60613.

r? @Centril

@bors bors closed this in #60873 May 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.