Bad error message with async main

[Nokel81]

If someone tries to do the following async fn main() -> Result<(), Box<dyn std::error::Error> the error message is not helpful (though it is technically correct).

error[E0277]: `main` has invalid return type `impl futures::Future`
  --> rs/agent-updater/src/main.rs:46:20
   |
46 | async fn main() -> Result<(), Box<dyn std::error::Error>> {
   |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `main` can only return types that implement `std::process::Termination`
   |
   = help: consider using `()`, or a `Result`

I think that it should point to the async keyword and say that standard rust does not support async main.

This issue has been assigned to @Nokel81 via this comment.

[Centril]

Implementation notes:

• This should probably be checked wherever we type check fn main.
• We need to propagate the Spanned from AST (https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.FnHeader.html#structfield.asyncness) to HIR (https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/struct.FnHeader.html#structfield.asyncness)

cc @estebank who has dealt with fn main diagnostics recently.

[estebank]

This is a good first-contribution ticket I can help with.

[Nokel81]

I will take you up on that offer Wednesday evening if that is good with you.

[Centril]

@rustbot assign @Nokel81

[Nokel81]

@rustbot claim

[Nokel81]

@estebank Though I realize it might be too late for today. But how should be chat?

[estebank]

I'm on the street now, but if you have specific questions I can answer them when I get home.

[Nokel81]

Work is going well. I should have a preliminary PR up early next week.

[Nokel81]

I have two things that I have run into:

1. should I be using rustc_span::source_map::dummy_spanned?
2. I am having trouble figuring out why I get a bug! panic at src/librustc_metadata/rmeta/decoder.rs:398: Cannot decode Span without Session., would anyone have an idea as to how to set up a Session?

[estebank]

@Nokel81 could you push your code to a branch we can look at and comment inline? You should be extracting an existing span.

[Nokel81]

1. There is a bunch of places in the code where map_or_else or a default hir::IsAsync::NotAsync was used and I needed to a way to make it Spanned<hir::IsAsync>
2. https://github.com/Nokel81/rust/tree/async_main_error
3. I am also having trouble trying to figure out where fn main is type checked as different then any other function.

[tmandry]

Ping from triage. @estebank, could you follow up?

[tmandry]

Ping. @estebank, is this something you can continue to mentor? @Nokel81, are you still interested in working on this?

[Nokel81]

I am still interested in working on this.

[nikomatsakis]

I'm looking quickly over the branch, @Nokel81.

@estebank or others may feel differently but my take:

I don't think it's a good idea to return Spanned<hir::IsAsync> if we are going to sometimes use a dummy span. I see that we do use a similar pattern for VisibilityKind, but I'm of the opinion that dummy spans should be avoided and should not be common.

If we were going to use Spanned, I'd want to avoid the dummy span, and instead use the span of the fn keyword or something when the function is not async.

However, we could also just just include the span for the "yes, is async" variant. This is what the ast::Async type does (see the Yes variant). We could certainly modify hir::Async to include a span just on the Yes variant as well. I don't see a ton of precedent for that in the HIR, but it seems reasonable.

[Nokel81]

Thanks for the quick look over @nikomatsakis. I am wondering what should happen if an error occurs where it is required to be async but isn't (maybe I am thinking too hard in the future).

I sort of like the span of the fn keyword solution, and it is definitely better than using a dummy value.

[nikomatsakis]

@Nokel81 we can solve that problem later, but in that scenario, having a "dummy span" on hand would not be especially useful anyway -- that is, though, I think the right question to be asking, which is why I suggested the span for the "fn" keyword (or perhaps the fn name). i.e., what would you want to highlight in such a case?

[nikomatsakis]

but perhaps better to wait until indeed we have such a message to emit, which might help clarify things

[Nokel81]

Makes sense, I'll see about transitioning my change set to that using hir::Async::Yes with span information.