async fn + rustfmt don't "just work" inside of RLS

[nikomatsakis]

If you create a new rust project in the RLS and try to use async fn:

async fn foo() { }
fn main() { }

you will get errors from rustfmt that async fn is not supported in the 2015 Edition when you attempt to format. This is true even if your project is in Rust 2018. Presumably the RLS is not supplying the correct version information. I view this as a fairly large "user experience" problem.

Note: Probably this should be filed on the RLS repository, but I wanted to file a bug here so that we could track it more easily as a potential blocker for stabilization (I would consider it to be one). I think in the future we should be tracking said bugs through repository-wise searches to avoid this sort of dilemma, but anyway.

cc @Xanewok -- any thoughts?

[Xanewok]

This is one of the cases where RLS is overzealous when it comes to making sure we've picked up a right edition, to the point where it refuses to do any work if it's not 100% sure (and it doesn't pick up the correct edition, which is another case).

To provide some more context on why's that, it's technically possible for a file to fall under multiple editions - an edge case where we have separate crates with different editions in Cargo.toml which pull in the same module. Since we issue format request for a given file, we do not disambiguate now and thus we first run analysis compilation, detect which files were part of a given crate and only then allow to format a file with a detected edition.

It seems that the edition detection has regressed recently so that's probably the case why it continues to not work in the 2018 edition - will look into it.

[cramertj]

Hey @Centril you're tagging all of this issues as async/await blocking -- can you explain why that is? IMO bugs in editors and things shouldn't block stabilization of async/await.

[Centril]

Hey @Centril you're tagging all of this issues as async/await blocking -- can you explain why that is? IMO bugs in editors and things shouldn't block stabilization of async/await.

Per Niko's note:

Note: Probably this should be filed on the RLS repository, but I wanted to file a bug here so that we could track it more easily as a potential blocker for stabilization (I would consider it to be one).

[cramertj]

@Xanewok have you had a chance to investigate this further?

[Xanewok]

@cramertj sorry, not yet. I'll work on this this week.

[cramertj]

@Xanewok Were you able to look into this?

[Xanewok]

Yeah, sorry for the radio silence.

Looking at this now, the edition is correctly inferred (if you use edition = "2018" in Cargo.toml that's now supplied by default for cargo new) in the code path but currently this fails on newest nightly due to

async fn is unstable

note: for more information, see https://github.com/rust-lang/rust/issues/50547
help: add #![feature(async_await)] to the crate attributes to enable

As it is now, if the analyzed code doesn't successfully compile as a whole the RLS doesn't update cached input files for crates in the workspace - which means the cache is empty and we're not 100% sure what should be edition and just bail.
That's something that we definitely should improve as it's bad user experience but this also means that sticking feature at the top like so:

#![feature(async_await)]

async fn foo() { }
fn main() { }

correctly causes cache to update and thus formatting to succeed, hopefully unblocking the work here.
@nikomatsakis @cramertj should we drop the async/await blocking label then?

[nikomatsakis]

Closing as fixed.

[omarabid]

I'm still having this problem with Rust 1.39 (stable) or Rust 1.41 (nightly) with rustfmt 1.4.9 (nightly).

[kenkoooo]

I have this problem with the IntelliJ plugin. It happened because the default edition of rustfmt is not 2018 but 2015. I resolved this issue by setting edition = "2018" in .rustfmt.toml.