Skip to content

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

Open
@nagisa

Description

@nagisa
Member

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)

Activity

added
F-doc_cfg`#![feature(doc_cfg)]`
T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.
B-unstableBlocker: Implemented in the nightly compiler and unstable.
on May 7, 2021
changed the title [-]`doc_cfg` does not have any effect on the re-exports[/-] [+]`doc_cfg` does not have any effect on the re-export items[/+] on May 7, 2021
changed the title [-]`doc_cfg` does not have any effect on the re-export items[/-] [+]`doc_cfg` does not have a correct effect on `use` items referencing other public items[/+] on May 7, 2021
est31

est31 commented on May 7, 2021

@est31
Member

I believe in this case we should show exactly the specified cfg badges

I agree.

You can only use something from a module if the module is available, which means that if there are multiple implementations of a module gated by different cfg attributes, but the use is free of any cfg, there should be no inheritance from the module that rustdoc ran for. Conversely, if the pub use contains a more restricted cfg than the module, you would want to document that restricted cfg instead of the module's cfg, because the use would simply not be available in some cases.

TLDR: pub use should only show what attributes on the use itself contain.

added a commit that references this issue on Dec 15, 2023

Rollup merge of rust-lang#113091 - GuillaumeGomez:prevent-cfg-merge-r…

ec0008a
added a commit that references this issue on Dec 15, 2023
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

    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

        Participants

        @nagisa@est31@camelid

        Issue actions

          `doc_cfg` does not have a correct effect on `use` items referencing other public items · Issue #85043 · rust-lang/rust