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

cargo test does not run doctests for cdylib #4717

Closed
rfdonnelly opened this issue Nov 13, 2017 · 3 comments
Closed

cargo test does not run doctests for cdylib #4717

rfdonnelly opened this issue Nov 13, 2017 · 3 comments

Comments

@rfdonnelly
Copy link

This is effectively a dupe of #2442. However, #2442 was closed without action. Having cargo test silently not run doctests for cdylib and other non-rlib crate types is a papercut. It is confusing for new users that do not know the implementation details of doctests.

A user should be informed of which tests are not being run, why, and how to resolve. This would cut down on time spent discovering why doctests are not run. Configuration should allow these messages to be disabled.

Discovery Process for Current Behavior

To debug why doctests were not being run, I had to search the cargo source for "Doc-tests" which led me to:

pub fn doctested(&self) -> bool {
This showed me that this behavior was intended and a function of crate-type but did not explain why. I then searched open issues, then closed issues and eventually found #2442 which gave some explanation.

Current Behavior

Running cargo test --doc on a new rlib successfully runs doctests:

$ cargo test --doc
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
   Doc-tests lib

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Running cargo test --doc on a new cdylib silently fails with:

$ cargo test --doc
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs

Expected Behavior

Running cargo test --doc on a cdylib should inform the user that doctests were not run:

$ cargo test --doc
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
   Doc-tests lib

warning: doc-tests can only be run on rlib, lib, and proc-macro crate-types
due to <terse explanation>.  This warning can be disabled by setting
doctest=false in the [lib] section of Cargo.toml.

Ideally, the message should inform the user of alternatives. I don't know what these are yet. Maybe adding "rlib" to crate-type in addition to what is already there. Or break up the code base into multiple crates so that doctest can be run on a subset.

Cargo Version

$ cargo --version
cargo 0.22.0 (3423351a5 2017-10-06)
@alexcrichton
Copy link
Member

This is a limitation of rustdoc, not Cargo, so I think you'll want to open an issue against rust-lang/rust

@stale
Copy link

stale bot commented Sep 19, 2018

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

  • Is this still relevant?
  • If so, what is blocking it?
  • Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

@stale stale bot added the stale label Sep 19, 2018
@stale
Copy link

stale bot commented Oct 19, 2018

As I didn't see any updates in 30 days I'm going to close this. Please see the previous comment for more information!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants