-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.Relevant to the rustdoc team, which will review and decide on the PR/issue.
Description
Hello,
consider this code example:
#![deny(missing_docs)]
#![deny(missing_doc_code_examples)]
//! crate level doc
//! ```
//! println!("hello"):
//! ```
/// doc
///
/// ```
/// println!("hello");
/// ```
fn test() {
}
// the allow() here works as expected, but missing_doc_code_examples still complains
#[allow(missing_docs)]
mod module1 {
fn test() {}
}
// here we want some docs but no code examples, but missing_doc_code_examples still complains
#[allow(missing_doc_code_examples)]
/// doc
mod module2 {
/// doc
fn test() {}
}
/// doc
///
/// ```
/// println!("hello");
/// ```
mod module3 {
// here we want some code examples but missing_doc_code_examples does not complain
/// doc
fn test() {}
}
Here I would expect the following behaviour when running cargo doc
:
module1
hasallow(missing_docs)
somissing_doc_code_examples
should be silentmodule2
hasallow(missing_doc_code_examples)
yet we still get errors for missing docs onmodule2
, I think we should notmodule3
has a code example, butmodule3::test
does not, we should get an error for the missing example onmodule3::test
Metadata
Metadata
Assignees
Labels
T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.Relevant to the rustdoc team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
do not deny on missing_doc_code_examples
GuillaumeGomez commentedon May 16, 2019
For
module1
, it's normal to get the error since bothmissing_doc_code_examples
isn't bound toallow(missing_docs)
. However, formodule3
it's very strange to not get anything. The strangest thing being that diagnostic is emitted there, we just don't see it.Rollup merge of rust-lang#60908 - GuillaumeGomez:errors, r=oli-obk
danieleades commentedon Nov 3, 2020
I feel like the title of this issue is slightly misleading. The behaviour is not simply unclear, it's totally broken.
GuillaumeGomez commentedon Nov 3, 2020
@danieleades The situation should have been improved since then. Do you still have a good example of where it's totally broken so we can continue to improve the whole situation?
danieleades commentedon Nov 3, 2020
yep.
steps to reproduce-
lib.rs
cargo +nightly build
rust: 1.49.0-nightly
GuillaumeGomez commentedon Nov 3, 2020
It works as expected for me:
danieleades commentedon Nov 3, 2020
presumably that's because you didn't follow my reproduction steps.
Is it the intended behaviour that this lint only fire if you're building documentation with rustdoc? If so, that's inconsistent with all the other lints
GuillaumeGomez commentedon Nov 3, 2020
It's only supposed to be triggered by rustdoc indeed (my bad, didn't see you didn't use the
doc
command). I don't see how it's inconsistent though? It's marked as such in the lint documentation.danieleades commentedon Nov 3, 2020
hmm i see after some digging that it's marked as 'rustdoc only' here - https://doc.rust-lang.org/beta/rustc/lints/listing/allowed-by-default.html#missing-doc-code-examples. Mea culpa.
Perhaps there are good historical or technical reasons why this is the case, but while i'm glad it's documented, simply describing the behaviour doesn't make it consistent.
this is inconsistent in the sense that out of ~120 or so rustc lints, there are how many that are 'rustdoc-only'? 2-3?
Given that the current behaviour is documented (though unexpected) I'm now in complete support of the issue title ;)
GuillaumeGomez commentedon Nov 3, 2020
You can see the list of the rustdoc lints there:
rust/compiler/rustc_lint/src/lib.rs
Lines 314 to 322 in 0d033de
GuillaumeGomez commentedon Mar 14, 2022
Seems like this issue was fixed so closing. Don't hesitate to reopen if something is still missing.