rustdoc doesn't execute documentation tests for #[target_feature] functions

[gnzlbg]

Example:

#![feature(target_feature)]

/// Foo
///
/// # Examples
///
/// ```
/// assert!(false);
/// ```
#[target_feature(enable="sse")]
pub unsafe fn foo() {}

$ cargo test

Doc-tests foo

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

[QuietMisdreavus]

I wonder if it has to do with #49225? I checked the sample with the nightlies that were made right before and after the change. The previous nightly finds the test, the next nightly does not:

$ rustdoc +nightly-2018-03-21 --test h.rs

running 1 test
test h.rs - foo (line 7) ... FAILED

failures:

---- h.rs - foo (line 7) stdout ----
        thread 'rustc' panicked at 'test executable failed:

thread 'main' panicked at 'assertion failed: false', h.rs:3:1
note: Run with `RUST_BACKTRACE=1` for a backtrace.

', librustdoc/test.rs:331:17
note: Run with `RUST_BACKTRACE=1` for a backtrace.


failures:
    h.rs - foo (line 7)

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

$ rustdoc +nightly-2018-03-24 --test h.rs

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

[QuietMisdreavus]

Oh wait, it's not that change, it's #48759 - it dynamically adds doc(cfg) flags to the item, which rustdoc reads before executing the doctests.

[gnzlbg]

@QuietMisdreavus can we revert the part of #48759 that adds doc(cfg) from #[target_feature] ? It is not working properly and it is at least unclear to me what the default behavior for this should be at this point. Not doing anything about it allows people to do whatever they want. Figuring a good default and coming at a working implementation might be easier if we have a body of working doc tests that can be studied.

[QuietMisdreavus]

After some conversations on IRC, we discovered that rustdoc doesn't add target features to the configuration environment when extracting and running doctests. I've opened #49864 to fix this.