Code change:
<ins> #![feature(doc_cfg)] #![feature(no_core)] #![crate_name = "foo"] #![no_core] // @has 'foo/index.html' // @has - '//*[@class="item-left module-item"]/*[@class="stab portability"]' 'foobar' // @has - '//*[@class="item-left module-item"]/*[@class="stab portability"]' 'bar' #[doc(cfg(feature = "foobar"))] mod imp_priv { // @has 'foo/struct.BarPriv.html' // @has - '//*[@id="main-content"]/*[@class="item-info"]/*[@class="stab portability"]'  //    'Available on crate feature foobar only.' pub struct BarPriv {} impl BarPriv { pub fn test() {} } } #[doc(cfg(feature = "foobar"))] pub use crate::imp_priv::*; pub mod bar { // @has 'foo/bar/struct.Bar.html' // @has - '//*[@id="main-content"]/*[@class="item-info"]/*[@class="stab portability"]'  //    'Available on crate feature bar only.' #[doc(cfg(feature = "bar"))] pub struct Bar; } #[doc(cfg(feature = "bar"))] pub use bar::Bar; </ins>

Related discussion:
text: From Given the following Rust code with in-line annotations of the expected behaviour: On: does not seem to be able to generate feature requirement labels on types in private modules () that are publicly reexported (). The labels do not show up on the module overview nor page, but do propagate into items like functions for the given type. This renders the type without any feature requirement, neither in the module overview: ! Nor on the page: ! Note that the label is propagated onto (does not have an explicit ), at least understood that! It is supposed to render the feature requirement for like , both in the module overview above as on the page: ! It seems tricky to combine feature requirements on the and reexport. In the case above they are the same, but what if: The type is only publicly available when and are specified. Specifying is fine but makes the contents of unreachable through the current module, specifying only should result in a "module not found" error. CC
This also affects re-exports of entire crates. Unfortunately there the fix is not clear at all, since the "parent" crate is obviously not guaranteed to have the same features as the crate being re-exported.
Within the same crate as well; it's not about the features that are enabled (though it is relevant which are available) but about the combined restrictions that are placed on the definition and reexport. Simplest I can think of is a union of all features (but gets complicated quick when inversions and vs is used) and later perhaps simplifying based on feature relations (if implies there is no need to display as requirement, if either definition or reexport requires ). That's necessary to cleanly solve crate reexports, since you effectively want to ensure that the top-level crate feature implies feature and hide it. If the whole resolver is made smart enough (perhaps this already exists, I'm not too familiar with Cargo) it could even throw warnings when there exist feature combinations that would lead to a compiler error (ie. explicitly reexporting a symbol that is not available for a certain set of features).
I wonder if this is just an ordering issue of the passes: The private modules have disappeared by the point where we pass all the data down so we don't see them.