cargo test doesn't compile doc tests for target != host

[therealprof]

Problem

We'd like to have no_run doc tests for embedded HAL impl crates to ensure that the crate is sufficiently and accurately documented. However cargo doc completely ignores those tests when running with the --doc flag:

# cargo test  --release  --features="stm32f042,rt" --doc
    Finished release [optimized + debuginfo] target(s) in 0.07s

while creating an error when trying to run all tests:

# cargo test  --release  --features="stm32f042,rt"
   Compiling stm32f0xx-hal v0.9.0 (/Users/egger/OSS/stm32f0xx-hal)
error[E0463]: can't find crate for `test`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: Could not compile `stm32f0xx-hal`.

I would expect that no_run tests are correctly compiled in the current environment (as are docs, libraries, executables and examples) and compile errors flagged as test failures. In the future it would be even nicer if I could define a test runner environment (like qemu or docker) to test the executables as well.

Steps

1. Obtain https://github.com/stm32-rs/stm32f0xx-hal
2. cargo test --release --features="stm32f042,rt" --doc
3. cargo test --release --features="stm32f042,rt"

Possible Solution(s)
Attempt to compile doctests even when target != host, especially no_run ones.

Notes

Output of cargo version:
cargo 1.33.0-nightly (2cf1f5d 2018-12-11)
cargo 1.31.0 (339d9f9 2018-11-16)

[ehuss]

I think this is intentional, see rust-lang/rust#31907. I wonder, how much risk there is that doc tests will fail to just compile on host?

See also rust-lang/rust#44404 for a request to have rustdoc support --target.

[alexcrichton]

Yes this is currently intentional that we don't run rustdoc at all, but it makes sense to me that we could have an option to try to at least compile examples even if we can't run them!

I suspect that we can't do this in a backwards compatible fashion by default, but at least having an option in the maniest for something like this seems reasonable to me

[therealprof]

@alexcrichton I fear that the inability to compile doc tests will have a major (negative) quality impact for embedded because there's no other way to build software but via cross-compilation. Thus it would be great if this feature would be given appropriate consideration and priority.

[ririsoft]

I fear that the inability to compile doc tests will have a major (negative) quality impact for embedded because there's no other way to build software but via cross-compilation. Thus it would be great if this feature would be given appropriate consideration and priority.

This also impacts developers using pc-windows-gnu target on a system where pc-windows-msvc is the default. I discovered a bug in my documentation thanks to a CI build running on linux, but I wish I discovered this earlier in my pipeline.

[jethrogb]

At the very least, I think cargo should error if you explicitly pass --doc and --target.

[therealprof]

Woohoo!