Skip to content

rustdoc: Emit a lint warning if doctest contains #[test] functions but isn't marked test_harness #157458

Open

Description

@programmerjake

I tried this code:

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=001bcadcd1efc090468ba6ce7231359b

/// ```
/// #[test]
/// fn my_test() {
///     panic!("this test should fail");
/// }
/// ```
const _: () = ();

I expected to see this happen: running cargo test would try to run my_test and report it failed.

Instead, this happened: it reports the doctest ran successfully.

I want to be able to use #[test] in a doctest to document things that are intended to only be used inside a #[test] (since they print errors to stdout/stderr and/or panic for better testing ergonomics, instead of returning a Result).

Meta

I tried it on 1.96.0 stable as well as 1.98.0-nightly (2026-06-03 b354133)

Activity

  1. added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Jun 4, 2026
  2. fmease commented on Jun 5, 2026

    @fmease
    Member

    While history could've taken a different branch where doctests that don't contain a main function and don't contain statements other than item statements get compiled under --test, in our reality that didn't happen and it would most likely require an edition to change this behavior (given under --test cfg test is active); well rustdoc could extend its naive "static analysis" of doctests and look for functions annotated with #[test] (which will have false positive like the existing checks) to contain the number of potential regressions.

    In any case, you can annotate your doctest with code block attribute test_harness to make it behave like you want:

    /// ```test_harness
    /// #[test]
    /// fn my_test() {
    ///     panic!("this test should fail");
    /// }
    /// ```
    const _: () = ();
    
    #[test]
    fn make_playground_default_to_test() {}
  3. fmease commented on Jun 5, 2026

    @fmease
    Member

    That attribute isn't documented currently, PR #148183 will rectify that.

  4. fmease commented on Jun 5, 2026

    @fmease
    Member

    Do you feel code block attribute test_harness is sufficient or would you like rustdoc to try to autodetect simple cases (fallibly)? As I said that might only be possible in a new edition depending on the complexity of the heuristic or the amount of crater regressions.

  5. added
    T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.
    C-feature-requestCategory: A feature request, i.e: not implemented / a PR.
    and removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    C-bugCategory: This is a bug.
    on Jun 5, 2026
  6. programmerjake commented on Jun 5, 2026

    @programmerjake
    MemberAuthor

    maybe emit a warning if it detects #[test] functions and you didn't use test_harness? that should work on all editions.

  7. fmease commented on Jun 5, 2026

    @fmease
    Member

    That sounds workable 👍

  8. added
    A-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.
    on Jun 5, 2026
  9. changed the title [-]#[test] fn my_test() in doctests should run[/-] [+]rustdoc: Emit a lint warning if doctest contains `#[test]` functions but isn't marked `test_harness`[/+] on Jun 5, 2026
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

    A-doctestsArea: Documentation tests, run by rustdocA-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.C-feature-requestCategory: A feature request, i.e: not implemented / a PR.T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions