Skip to content

doc_cfg does not have a correct effect on use items referencing other public items #85043

Open
@nagisa

Description

@nagisa

Consider the following code:

#[doc(cfg(feature="include_file"))]
pub mod include_file {
    pub fn generated() {}
}

pub use include_file::*;
pub use include_file::generated;
pub use include_file::generated as renamed;

The produced documentation looks like this:

An image of rustdoc output for the crate root, showing 3 reexports, use include_file::* which has a doc_cfg badge, and use include_file::generated as well as use include_file::generated as renamed which don't

I think we should be showing the doc_cfg badge consistently here: either on all of the re-exports or none of them. I would probably lean towards "none" in this particular case, in part because it would be easier to implement properly situations where re-exports don't share the features of the modules that are being re-exported. For instance:

#[doc(cfg(feature="include_file"))]
pub mod include_file {
    pub fn generated() {}
}
#[doc(cfg(feature="reexport_glob"))]
pub use include_file::*;
#[doc(cfg(feature="reexport_generated"))]
pub use include_file::generated;
#[doc(cfg(feature="reexport_renamed"))]
pub use include_file::generated as renamed;

which generates exactly the same documentation page as shown above. I believe in this case we should show exactly the specified cfg badges, rather than attempting to infer from what items are being re-exported.

(related #83428, #43781)

Metadata

Metadata

Assignees

No one assigned

    Labels

    B-unstableBlocker: Implemented in the nightly compiler and unstable.C-bugCategory: This is a bug.F-doc_cfg`#![feature(doc_cfg)]`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