codegen/doc: Omit "Feature: vXXX" text in favour of doc_cfg

[MarijnS95]

Nowadays we have the doc_cfg feature rendering clean, consistent and obvious markers for feature requirements through doc(cfg()) attributes in the code (perhaps automatically derived from cfg() attributes in the not so distant future). With this it is not necessary to repeat the requirement in the documentation text once again, which wasn't really obvious nor good-looking to begin with.

Besides, this "Feature:" text is currently erroneously generated on the last member of an enum, instead of on the enum itself (parts omitted for brevity):

#[cfg(any(feature = "v1_14_1", feature = "dox"))]
#[cfg_attr(feature = "dox", doc(cfg(feature = "v1_14_1")))]
pub enum WebRTCFECType {
    /// none
    None,
    /// ulpfec + red
    ///
    /// Feature: `v1_14_1`
    ///
    UlpRed,
}

Note that other documentation comments on the enum are correctly generated on the enum itself.

[GuillaumeGomez]

The problem is that doc_cfg is unstable and that it'll be removed in a not so far future. I really don't think this is a good idea here...

[MarijnS95]

@GuillaumeGomez You mean this was just some nightly experiment that will disappear entirely? Will it be superseded by automatically detecting the feature from #[cfg()] directly or have no immediate replacement at all until much later?

[GuillaumeGomez]

The goal is to make rustdoc aware of the cfg attributes directly so there is no need for the doc(cfg). A PR is already in progress. The end goal being to completely remove it.

[MarijnS95]

The goal is to make rustdoc aware of the cfg attributes directly so there is no need for the doc(cfg). A PR is already in progress. The end goal being to completely remove it.

@GuillaumeGomez That's really good news, but that still means the vx_xx features are rendered in the HTML right? That is still a valid reason to remove this now-superfluous comment from the documentation, now?

[GuillaumeGomez]

I'm not sure of what you mean. My point is that I'm worried that using an unstable feature might prevent users to generate doc locally or even break our crates' code. The update on rustdoc side will add it automatically depending on the cfg.

[sdroege]

My point is that I'm worried that using an unstable feature

That's already the case with the current docs. They only build with nightly.

[MarijnS95]

I'm not sure of what you mean. My point is that I'm worried that using an unstable feature might prevent users to generate doc locally or even break our crates' code. The update on rustdoc side will add it automatically depending on the cfg.

The unstable feature is already fully in use and docs (if dox is enabled) already build with that. This PR does nothing to change or prolong that requirement. It only removes some redundant (again, if building with doc_cfg) text from the documentation body.

In other words: if you want the textual Feature: vXXX message to stay until doc_cfg is stabilized and everyone can build (implicitly) with the dox feature without nightly, this PR should be stashed for a bit.