rustdoc drops inlined cross-crate re-exported `#[target_feature(enable = "…")]` from "cfg badge"

That's because rustdoc solely uses rustc_attr_ir's attributes for this but we (I would say intentionally) doesn't encode AttributeKind::TargetFeature in the crate metadata (source).

While it would be trivial to fix this by changing the No to Yes as extract_cfg_from_attrs (source) would then be able to pick it up even for inlined cross-crate re-exported definitions, it would make me quite sad since we actually do have this information available in the crate metadata, namely via CodegenFnAttrs. So ideally we'd query tcx.codegen_fn_attrs(…).target_features instead (just need to filter by TargetFeatureKind::Enabled) to avoid storing things redundantly (wasting disk space & maybe time encoding/decoding).

However, I fear that modifying extract_cfg_from_attrs to also draw from codegen_fn_attrs apart from the provided attrs would be tricky to do correctly with all the "cfg inheritance" going on or rather because we probably don't want to unconditionally append fn target features (after all, the attrs parameter currently dictates the original set of attrs). Can we rewrite the whole logic or is that not even necessary? Needs investigation.

Repro

1. rustc a.rs --crate-type=lib where a.rs:

   #[target_feature(enable = "avx")]
   pub fn func() {}
   

2. rustdoc b.rs --edition 2024 --extern a -L. where b.rs:

   #![feature(doc_cfg)]
   pub use a::*;
   

Start with compiler/rustc_attr_ir/src/encode_cross_crate.rs and src/librustdoc/clean/cfg.rs, especially extract_cfg_from_attrs, then inspect how CodegenFnAttrs and codegen_fn_attrs expose enabled target features. Run the two-command reproduction with a.rs and b.rs; done means the inlined cross-crate re-export retains its target-feature cfg badge without redundant metadata encoding.