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

rustdoc: issues with some async syntax #53203

Closed
ehuss opened this issue Aug 8, 2018 · 1 comment · Fixed by #53226
Closed

rustdoc: issues with some async syntax #53203

ehuss opened this issue Aug 8, 2018 · 1 comment · Fixed by #53226
Assignees
Labels
A-rust-2018-preview Area: The 2018 edition preview C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@ehuss
Copy link
Contributor

ehuss commented Aug 8, 2018

Rustdoc seems to fail on async syntax in some situations.

With edition = "2018" in Cargo.toml, the following is a sample of some apparent issues.

#![feature(rust_2018_preview, async_await, futures_api)]
#![allow(unused)]

use std::future::Future;

struct S;

impl S {
    async fn f() {}
}

fn f() {
    async move { };
}

fn async_closure(x: u8) -> impl Future<Output = u8> {
    (async move |x: u8| -> u8 {
        x
    })(x)
}

This should build fine, but fails when running rustdoc:

cargo +376b60da8b65d7c4392f0a5e2b45c42e84bd01ce doc
 Documenting ed v0.1.0 (file:///Users/eric/Proj/rust/cargo/scratch/ed)
error: missing `fn`, `type`, or `const` for impl-item declaration
 --> src/lib.rs:8:9
  |
8 |   impl S {
  |  _________^
9 | |     async fn f() {}
  | |____^ missing `fn`, `type`, or `const`

error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `move`
  --> src/lib.rs:13:11
   |
13 |     async move { };
   |           ^^^^ expected one of 8 possible tokens here

error: expected one of `!`, `)`, `,`, `.`, `::`, `?`, `{`, or an operator, found `move`
  --> src/lib.rs:17:12
   |
17 |     (async move |x: u8| -> u8 {
   |            ^^^^ expected one of 8 possible tokens here

error[E0277]: the trait bound `(): std::future::Future` is not satisfied
  --> src/lib.rs:16:28
   |
16 | fn async_closure(x: u8) -> impl Future<Output = u8> {
   |                            ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::future::Future` is not implemented for `()`
   |
   = note: the return type of a function must have a statically known size

error: Compilation failed, aborting rustdoc

error: Could not document `ed`.

Caused by:
  process didn't exit successfully: `rustdoc -Zunstable-options --edition=2018 --crate-name ed src/lib.rs -o /Users/eric/Proj/rust/cargo/scratch/ed/target/doc -L dependency=/Users/eric/Proj/rust/cargo/scratch/ed/target/debug/deps` (exit code: 1)

Tested with a few different nightlies (rustc 1.30.0-nightly (73c7873 2018-08-05)) and latest master (376b60d).

@QuietMisdreavus QuietMisdreavus self-assigned this Aug 9, 2018
@QuietMisdreavus QuietMisdreavus added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. C-bug Category: This is a bug. A-rust-2018-preview Area: The 2018 edition preview labels Aug 9, 2018
@QuietMisdreavus
Copy link
Member

This is a bug between rustdoc and rustc_driver, where the only place that sessopts.edition is handed to libsyntax is this specific all-in-one entry point to the compiler:

pub fn run_compiler<'a>(args: &[String],
callbacks: Box<dyn CompilerCalls<'a> + sync::Send + 'a>,
file_loader: Option<Box<dyn FileLoader + Send + Sync + 'static>>,
emitter_dest: Option<Box<dyn Write + Send>>)
-> (CompileResult, Option<Session>)
{
syntax::with_globals(|| {
let matches = match handle_options(args) {
Some(matches) => matches,
None => return (Ok(()), None),
};
let (sopts, cfg) = config::build_session_options_and_crate_config(&matches);
hygiene::set_default_edition(sopts.edition);
driver::spawn_thread_pool(sopts, |sopts| {
run_compiler_with_pool(matches, sopts, cfg, callbacks, file_loader, emitter_dest)
})
})
}

However, since rustdoc manages the phases of compilation itself, this line is never hit, and thus the global state telling libsyntax what edition to use is not set. We use this call manually for building doctests (see #52385), but not anywhere else. I propose moving the hygiene::set_default_edition call from run_compiler to phase_1_parse_input, right before it sets up the parse session. That way, rustdoc can continue to set the edition in the session options, and other consumers of librustc_driver aren't caught by this gotcha. @rust-lang/compiler

kennytm added a commit to kennytm/rust that referenced this issue Aug 14, 2018
…=estebank

driver: set the syntax edition in phase 1

Fixes rust-lang#53203

It seems the way libsyntax handles the desired edition is to use a global, set via `syntax_pos::hygiene::set_default_edition`. Right now, this is set in the driver in `run_compiler`, which is the entry point for running the compiler all the way through to emitting files. Since rustdoc doesn't use this function, it wasn't properly setting this global. (When initially setting up editions in rustdoc, i'd assumed that setting `sessopts.edition` would have done this... `>_>`) This was "fixed" for doctests in rust-lang#52385, but rather than patching in a call to `set_default_edition` in all the places rustdoc sets up the compiler, i've instead moved the call in the driver to be farther in the process. This means that any use of `phase_1_parse_input` with the right session options will have the edition properly set without having to also remember to set libsyntax up separately.

r? @rust-lang/compiler
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rust-2018-preview Area: The 2018 edition preview C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants