rustdoc features doctests conditional on cfg or target feature but that's not RFC'ed, not tested, not really documented and somewhat broken

[fmease]

Uplifted from #138907 (comment). While reviewing #138907 I found out that rustdoc intentionally skips¹ doctests if the #[doc(cfg(…))] (unstable feature doc_cfg, #43781) or #[target_feature(enable = "…")] (stable) on the owning item doesn't match².

E.g., rustdoc file.rs --test doesn't execute any tests where file.rs:

#![feature(doc_cfg)]

/// ```
/// assert!(true);
/// ```
#[doc(cfg(spec))]
fn f() {}

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

but also notice the "0 ignored". Passing --cfg spec executes the doctest:

running 1 test
test t.rs - f (line 3) ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Similarly:

/// ```
/// assert!(true)
/// ```
#[target_feature(enable = "feat")]
fn f() {}

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

because rustdoc treats #[target_feature(enable = "…")] as a #[cfg(…)] for all practical matters.

---

While that seems like a nifty feature, it's also a bit surprising and undiscoverable! Moreover, the #[doc(cfg(…))] part is not part of RFC 3631 and I believe the #[target_feature(enable = "…")] part was accidentally "stabilized" / "leaked on stable" in one of the PRs implementing doc_cfg (however I've yet to verify the latter claim).

It is briefly mentioned in the rustdoc book in the unstable features chapter: https://doc.rust-lang.org/rustdoc/unstable-features.html#doccfg-recording-what-platforms-or-features-are-required-for-code-to-be-present.

However, there don't seem to be any tests for this "feature" (I removed the logic and ran tests/{rustdoc{,-ui},run-make} and nothing failed).

Re. "somewhat broken": As alluded to, libtest shows "0 ignored" if the doctest is skipped. That's because rustdoc straight up doesn't consider the item testable and doesn't process the doctests at all! I'm not sure if others would consider that broken or a good feature / logical consequence. I need to think about that.

Footnotes

1. I.e., not in the libtest's "ignored" sense. ↩

2. I have no idea what that means for target features which I'm personally not really familiar with. E.g., my question is: Does a #[target_feature(enable = "…")] "ever match"? ↩