Skip to content

rustc panics when doctest cannot compile #48394

Description

@tforgione

I'm not sure if this is really a bug or not, but in CONTRIBUTING.md there is

If you're not sure if something is a bug or not, feel free to file a bug anyway.

so I might as well open this issue.

Basically, my MCVE is the following: run cargo init hello, and in lib.rs, and add the following:

/// This is a function
///
/// ```
/// no
/// ```
pub fn foo() {}

So, this doc comment should not compile, but when I run cargo test, I get (among other things) the following:

thread 'rustc' panicked at 'couldn't compile the test', /checkout/src/librustdoc/test.rs:286:13
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at /checkout/src/libstd/sys_common/backtrace.rs:68
             at /checkout/src/libstd/sys_common/backtrace.rs:57
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:391
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:538
   6: rustdoc::test::run_test
             at /checkout/src/librustdoc/test.rs:286

If I understood things well, I think rustc should never panics (but I could be wrong) and that's why I opened this issue.

Activity

  1. added
    T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.
    I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
    on Feb 21, 2018
  2. QuietMisdreavus commented on Feb 22, 2018

    @QuietMisdreavus
    Contributor

    So, after some investigation, i can say that this is basically intentional. First off, yes, there is a literal panic!() statement in the part of rustdoc that runs the tests:

    rust/src/librustdoc/test.rs

    Lines 283 to 297 in b1f8e6f

    match (compile_result, compile_fail) {
    (Ok(()), true) => {
    panic!("test compiled while it wasn't supposed to")
    }
    (Ok(()), false) => {}
    (Err(()), true) => {
    if error_codes.len() > 0 {
    let out = String::from_utf8(data.lock().unwrap().to_vec()).unwrap();
    error_codes.retain(|err| !out.contains(err));
    }
    }
    (Err(()), false) => {
    panic!("couldn't compile the test")
    }
    }

    ...But as far as i can tell, this is basically the only way to signal to the test handler that the test failed. The tests that run through rustdoc act the same way as regular unit tests, which show a similar panic message:

    #[cfg(test)]
    #[test]
    fn bar() { panic!("the disco"); }
    $ rustc +nightly --test e.rs
    $ ./e
    
    running 1 test
    test bar ... FAILED
    
    failures:
    
    ---- bar stdout ----
            thread 'bar' panicked at 'the disco', e.rs:10:12
    note: Run with `RUST_BACKTRACE=1` for a backtrace.
    
    
    failures:
        bar
    
    test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

    ...only here, the panic originates in user code, not rustdoc. With exactly the same code as your demo (just the word "no"), it completely fails to compile, but rustdoc doesn't have that luxury - it needs to compile as part of the test. Maybe with the proposed work on the testing system, this can get nicer, but for now can be considered intentional.

    Thanks for the report!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions