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

Marking a doctest code block as edition2018 causes it not to run #65980

Closed
DevJac opened this issue Oct 30, 2019 · 3 comments · Fixed by #66238
Closed

Marking a doctest code block as edition2018 causes it not to run #65980

DevJac opened this issue Oct 30, 2019 · 3 comments · Fixed by #66238
Labels
A-doctests Area: Documentation tests, run by rustdoc C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@DevJac
Copy link

DevJac commented Oct 30, 2019

I have a fresh Rust library, started with cargo new --lib foo, and I have the following in lib.rs:

/// Adds 1
/// ```edition2018
/// assert_eq!(1 + 1, 999)
/// ```
pub fn add_1(n: i32) -> i32 {
    n + 1
}

I can cargo build and cargo test this library. The doctest is obviously never run because 1 + 1 == 999 is false. The output from cargo test confirms this, showing that zero test were run.

The doctest book lead me to believe the doctest should still work, even if marked as edition2018.

Cargo.toml is:

[package]
name = "foo"
version = "0.1.0"
authors = ["..."]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
cargo version: cargo 1.38.0 (23ef9a4ef 2019-08-20)
rustc version: rustc 1.38.0 (625451e37 2019-09-23)
@ehuss
Copy link
Contributor

ehuss commented Oct 31, 2019

That's really strange! It works on nightly...any nightly!

I think it is due to this code:

x if allow_error_code_check && x.starts_with("edition") => {
// allow_error_code_check is true if we're on nightly, which
// is needed for edition support
data.edition = x[7..].parse::<Edition>().ok();

Was this maybe forgotten to be stabilized when editions were stabilized?

@Alexendoo Alexendoo added A-doctests Area: Documentation tests, run by rustdoc C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Nov 6, 2019
@DevJac
Copy link
Author

DevJac commented Nov 8, 2019

This still happens with Rust 1.39.0. I created a minimal project that demonstrates this bug at https://github.com/DevJac/rust_edition2018_doctest_bug_demo .

@ehuss
Copy link
Contributor

ehuss commented Nov 9, 2019

I posted PR #66238 to fix this.

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Nov 17, 2019
…GuillaumeGomez

rustdoc: Stabilize `edition` annotation.

The rustdoc `edition` annotation is currently ignored on stable. This means that the tests will be ignored, unless there is a `rust` annotation, then it will use the global edition. I suspect this was just an oversight during the edition stabilization, but I don't know. Example:

```rust
/// ```edition2018
/// // This code block was ignored on stable.
/// ```

/// ```rust,edition2018
/// // This code block would use whatever edition is passed on the command line.
/// ```
```

AFAIK, it is not possible to write a test that verifies stable behavior, as all tests appear to set RUSTC_BOOTSTRAP which forces all tests to run as "nightly", even on a stable release.

Closes rust-lang#65980
@bors bors closed this as completed in d67ca28 Nov 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-doctests Area: Documentation tests, run by rustdoc 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.

3 participants