doc_auto_cfg no longer applies a cfg badge to certain inlined cross-crate re-exported items with a #[cfg]

[epage]

I tried something like this code:

clap_builder:

#[cfg(feature = "env")]
pub fn env() {}

clap:

pub use clap_builder::env;

I expected to see this happen: a cfg badge appears in both clap and clap_builders docs for this function

Instead, this happened: the cfg badge only appears on clap_builder

Meta

docs.rs build on 2025-03-27 (4.5.34) worked for clap and clap_builder

docs.rs build on 2025-04-01 (4.5.35) didn't work for clap while clap_builder did

clap diff

clap_builder diff

Backtrace

<backtrace>

[fmease]

The search results for the GH query is:pr is:closed is:merged label:T-rustdoc merged:2025-03-25..2025-04-01 contain two potential candidates:

1. expand: Leave traces when expanding cfg attributes #138844
2. [rustdoc] Remove duplicated loop when computing doc cfgs #138755

[fmease]

Actually, this never(?) worked for free items (as contained in the issue description), only ever(?) for associated items. That's odd on its own and should be dealt with, too. The question is: Which of the two is the expected behavior? Not accurate, free items are also affected if downstream uses a glob import instead of explicitly/individually naming the item(s) in question (that's still odd, tho, and needs to be investigated).

[fmease]

MCVE:

rustc dep.rs --crate-type=lib --cfg cond:

pub struct Owner;
impl Owner { #[cfg(cond)] pub fn func() {} 

rustdoc usr.rs -L.:

#![feature(doc_auto_cfg)]
extern crate dep;
pub use dep::Owner;

[fmease]

My crude manual bisection leads me to believe that PR #138844 most likely regressed this.

[fmease]

MCVE with a free item (the glob import over an explicit/individual import is imperative for the repro (the latter never "worked")):

rustc dep.rs --crate-type=lib --cfg cond:

#[cfg(cond)] pub fn func() {}

rustdoc usr.rs -L.:

#![feature(doc_auto_cfg)]
extern crate dep;
pub use dep::*;

[fmease]

cc @GuillaumeGomez

[GuillaumeGomez]

I'm gonna take a look once #138907 will be merged.

[fmease]

I think we now simply need to look for cfg_trace and cfg_attr_trace instead of cfg and cfg_attr respectively when we're cross-crate inlining.

I haven't investigated anything that's just what I remember from reading petrochenkov's PRs when they were newly opened.

[GuillaumeGomez]

Yes we do but it's already done in #138907 so I think it's better to check if it's still an issue once merged to reduce the workload for us. :3

[Nemo157]

Huh, I'm surprised that ever worked, how is rustdoc supposed to know whether these cfg should be shown? They make sense in the case of façade crates with the same set of features as the crates they reëxport from, but not in other reëxport cases (and not every façade crate will use the exact same feature names as their components too).