Doctest cannot find reexported proc-macro crate when --target is given

[kennytm]

Repro step:

Execute these in the shell:

cargo init --lib
echo 'serde = { version = "1.0", features = ["derive"] }' >> Cargo.toml
echo 'extern crate serde;' > src/lib.rs
cargo test --target x86_64-apple-darwin

(The x86_64-apple-darwin should be replaced by the HOST triple. The same happens with x86_64-unknown-linux-gnu as the HOST.)

Actual result:

The doc test failed by complaining serde_derive not found:

   Doc-tests test2
error[E0463]: can't find crate for `serde_derive` which `serde` depends on
 --> $DIR/src/lib.rs:1:1
  |
1 | extern crate serde;
  | ^^^^^^^^^^^^^^^^^^^ can't find crate

• Adding a [dev-dependencies] to serde_derive will not solve it.
• Depending on serde_derive directly in [dependencies] + extern crate serde_derive; will solve it (but it defeats the purpose of features = ["derive"])

---

The problem is that libserde_derive-* are placed in the HOST folder (target/debug/deps), while libserde-* is in the TARGET folder (target/<triple>/debug/deps). rustdoc is executed only with -L dependency=target/<triple>/debug/deps, so libserde_derive-* is not found.

$ find . -name libserde*
./target/debug/deps/libserde_derive-277a82a8f5bc6353.dylib
./target/debug/deps/libserde_derive-277a82a8f5bc6353.dylib.dSYM
./target/debug/deps/libserde_derive-277a82a8f5bc6353.dylib.dSYM/Contents/Resources/DWARF/libserde_derive-277a82a8f5bc6353.dylib
./target/debug/deps/libserde_derive_internals-558d9b0ee0da671d.rlib
./target/x86_64-apple-darwin/debug/deps/libserde-5b01ff1fa5c50deb.rlib

---

Versions

$ rustc -vV
rustc 1.20.0-nightly (696412de7 2017-07-06)
binary: rustc
commit-hash: 696412de7e4e119f8536686c643621115b90c775
commit-date: 2017-07-06
host: x86_64-apple-darwin
release: 1.20.0-nightly
LLVM version: 4.0

$ cargo -vV
cargo 0.21.0-nightly (eb6cf012a 2017-07-02)
release: 0.21.0
commit-hash: eb6cf012a6cc23c9c89c4009564de9fccc38b9cb
commit-date: 2017-07-02

[parched]

Duplicate of #4224 by the sounds of things

[kennytm]

@parched Seems so. Thanks for the pointer.