cargo test --workspace ignores target for doctests only in workspaces

[bkolobara]

Problem

The behaviour around doctests in the top crate and workspaces is inconsistent when using a custom target.

Steps

If I use a custom target inside of .cargo/config.toml, e.g.:

[build]
target = "wasm32-wasi"

[target.wasm32-wasi]
runner = "lunatic"

And run cargo test --workspace. All regular tests in the top crate and tests in the workspaces are correctly compiled to the target and run with the specified runner.

This is not true for doctests. In the top crate they are skipped (I assume because wasm32-wasi is not supported for doctests). But in workspace crates they are compiled to the default target and fail.

Possible Solution(s)

I would expect them to behave the same in sub-crates and just be skipped.

Notes

No response

Version

cargo 1.62.0 (a748cf5a3 2022-06-08)
release: 1.62.0
commit-hash: a748cf5a3e666bc2dcdf54f37adef8ef22196452
commit-date: 2022-06-08
host: aarch64-apple-darwin
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.79.1 (sys:0.4.51+curl-7.80.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 12.4.0 [64-bit]

[ehuss]

Thanks for the report! Can you provide an example layout of projects that exhibits the problem? Either as text here, or as a temporary GitHub repo would be helpful. For example, the following works for me:

# Root Cargo.toml
[workspace]
members = ["bar"]
[package]
name = "foo"
version = "1.0.0"

And have src/lib.rs and bar/Cargo.toml and bar/src/lib.rs and .cargo/config.toml with your example. cargo test --workspace skips the doctests for both foo and bar.

It is a known issue that doctests aren't run with --target. The -Zdoctest-xcompile flag can enable that.

[bkolobara]

I have crated a minimal example project here: https://github.com/bkolobara/reproduce_cargo_issue

While crating it, I realised the issue only came up for proc-macro members that contain:

[lib]
proc-macro = true

in their Cargo.toml file.

When running cargo test --workspace for the example it prints out:

% cargo test --workspace                                                  
    Finished test [unoptimized + debuginfo] target(s) in 0.00s
     Running unittests src/lib.rs (target/debug/deps/bar-0032a48ca7a7281a)

running 0 tests

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

     Running unittests src/main.rs (target/wasm32-wasi/debug/deps/foo-303c22b83ea0a6a3.wasm)

running 0 tests

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

   Doc-tests bar

running 1 test
test src/lib.rs - _test (line 1) ... ok

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

The doctest doesn't run for the foo crate, but runs for the member bar. If I remove the proc-macro = true statement from member it works the expected way (no doctest run):

% cargo test --workspace
    Finished test [unoptimized + debuginfo] target(s) in 0.00s
     Running unittests src/lib.rs (target/wasm32-wasi/debug/deps/bar-8975f9ba6c0b95dd.wasm)

running 0 tests

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

     Running unittests src/main.rs (target/wasm32-wasi/debug/deps/foo-303c22b83ea0a6a3.wasm)

running 0 tests

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

I assume it's related to proc-macros always being compiled to the default target.

[ehuss]

Ah, thanks for putting that together! Yea, a proc-macro is always forced to be tested on the host target regardless of what was requested because proc-macros usually cannot be tested on the target (because they need to link into the compiler). I understand that isn't particularly obvious, but I don't think that is behavior we can change.

[ehuss]

I'm going to close as this is mostly working as intended. There is issue #7040 tracking better support for doctest cross-testing. Additionally rust-lang/rust#50784 is open for running doctests in binaries (which is the case in the reproduction).