Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign uprustdoc --test ignores visibility #30094
Comments
steveklabnik
added
the
T-rustdoc
label
Feb 9, 2016
steveklabnik
added
the
T-tools
label
Mar 9, 2017
steveklabnik
added
T-dev-tools
and removed
T-tools
labels
May 18, 2017
Mark-Simulacrum
added
C-feature-request
I-needs-decision
labels
Jul 24, 2017
QuietMisdreavus
referenced this issue
May 31, 2018
Open
1.26.0 - stdsimd/coresimd/x86/mod.rs test failures on non-x86 architectures #50988
QuietMisdreavus
self-assigned this
May 31, 2018
QuietMisdreavus
referenced this issue
Sep 21, 2018
Closed
rustdoc: don't run doctests on private items (by default) #54438
This comment has been minimized.
This comment has been minimized.
|
I've opened #54438 to filter out doctests on non-public items, but to also allow them to still be run with |
This comment has been minimized.
This comment has been minimized.
|
Based on the discussion in that PR, it seems like introducing such a change would be too controversial and will cause some existing doctests to stop being executed (by default). I do agree that such doctests are not useful to write, but introducing such a change is basically like breaking existing code - even though we're not causing something to fail that wasn't, we'd be stopping tests from executing that were being run before. Since that behavior has been in place all this time (the original issue was filed almost three years ago!), it's basically too entrenched to give up. I'm closing this issue in light of this. |
ilammy commentedNov 28, 2015
Consider the following use case.
I'd expect rustdoc to compile and run doctests only for the public::function since that's the only thing exported from the example crate and thus accessible to rustdoc.
However, this is what I see (actual for current stable (1.4.0) and nightly (1.6, bac2b13) builds):
Rustdoc's intent, as I understand it, is documenting public API. Private items do not show up in docs (unless one explicitly disables the pass that strips them). I believe this should also include doctests.
It's natural to use the items being documented in doctest examples, but such examples for private items would not compile due to obvious reasons. I believe analyzing the code snippets is a bit overkill for rustdoc, but it's pretty reasonable to simply strip any doctests for private items (at least by default), assuming that they contain internal code examples and will not not compile outside of the crate being documented.
Not using documentation comments for private items or marking private code examples with
ignoreavoids the issue, but personally I think that these are poor workarounds. If private doctests are ignored by default then exporting a previously private item (together with its documentation) is simply a matter of adding pub to it (or to its module import in the crate). However, if any of these workarounds are used then one must explicitly convert regular comments to documentation comments and/or removeignorefrom doctests in order to get everything right.Some links to (somewhat) related issues:
useandextern crate