[crate locator] Specified --extern crate is not appearing in dep-info (with -Zbinary-dep-depinfo)

This is an issue with the rustc compiler. I'll describe what is happening, while we work on providing a minimal test case. Summary: the dep-info emitted does not reflect --extern CRATE=LOCATION.

We have code that uses async-trait, that is compiled like so:

rustc \
--crate-name my_crate \
--crate-type rlib \
--emit=dep-info=host_x64-novariant/.../libmy_crate.rlib.d,link \
-Zbinary-dep-depinfo \
-Zdep-info-omit-d-target \
-Ldependency=host_x64 \
--extern async_trait=host_x64-novariant/libasync_trait-c6b6d222802967e6.so \
...

There happens to be two identical copies of libasync_trait-c6b6d222802967e6.so:

host_x64/libasync_trait-c6b6d222802967e6.so
host_x64-novariant/libasync_trait-c6b6d222802967e6.so

No need to concern with what '-novariant' means, think of it as just two directories with different names.

I expect the libmy_crate.rlib.d dep-info file to contain host_x64-novariant/libasync_trait-c6b6d222802967e6.so, however, it only contains host_x64/libasync_trait-c6b6d222802967e6.so. I expect this because of the comments describing https://github.com/rust-lang/rust/blob/master/compiler/rustc_metadata/src/locator.rs. Contrary to the description, it chose to use a library it found in a search path, rather than the one given by --extern.

Evidence from RUSTC_LOG=debug: It looks like locator finds multiple candidates for libasync_trait, even when we've specified --extern. The one that is shown in the dep-info file is not from --extern.

INFO rustc_metadata::creader resolving dep crate async_trait hash: `e023c8c27a1aa816` extra filename: `-c6b6d222802967e6`
INFO rustc_metadata::creader resolving crate `async_trait`
INFO rustc_metadata::creader falling back to a load
INFO rustc_metadata::locator lib candidate: host_x64-novariant/libasync_trait-c6b6d222802967e6.so
INFO rustc_metadata::locator lib candidate: host_x64/libasync_trait-c6b6d222802967e6.so
INFO rustc_metadata::locator dylib reading metadata from: /usr/local/home/fangism/project/out/default/host_x64-novariant/libasync_trait-c6b6d222802967e6.so
INFO rustc_metadata::locator Rejecting via proc macro: expected false got true
INFO rustc_metadata::locator metadata mismatch
INFO rustc_metadata::locator dylib reading metadata from: /usr/local/home/fangism/project/out/default/host_x64/libasync_trait-c6b6d222802967e6.so
INFO rustc_metadata::locator Rejecting via proc macro: expected false got true
INFO rustc_metadata::locator metadata mismatch
INFO rustc_metadata::locator lib candidate: host_x64-novariant/libasync_trait-c6b6d222802967e6.so
INFO rustc_metadata::locator lib candidate: host_x64/libasync_trait-c6b6d222802967e6.so
INFO rustc_metadata::locator lib candidate: host_x64-novariant/libasync_trait-c6b6d222802967e6.so
INFO rustc_metadata::locator lib candidate: host_x64/libasync_trait-c6b6d222802967e6.so
INFO rustc_metadata::locator dylib reading metadata from: /usr/local/home/fangism/project/out/default/host_x64-novariant/libasync_trait-c6b6d222802967e6.so
INFO rustc_metadata::locator dylib reading metadata from: /usr/local/home/fangism/project/out/default/host_x64/libasync_trait-c6b6d222802967e6.so
INFO rustc_metadata::creader register crate `async_trait` (cnum = 171. private_dep = false)

Why this matters? We consume the .d dep-info file (with -Zbinary-dep-depinfo) as a source-of-truth for what files/crates/dylibs are needed for remote building, and upload them. If this is inaccurate, all bets are off concerning the success of the remote build. (In the above scenario, failing to upload host_x64-novariant/libasync_trait-c6b6d222802967e6.so results in the async trait being un-recognized in the remote build, even though host_x64/libasync_trait-c6b6d222802967e6.so is uploaded (identical copy, different path).)

I suspect this can be reproduced independent of async-trait, that this is really a crate location matter.

rust-lang / rust

[crate locator] Specified --extern crate is not appearing in dep-info (with -Zbinary-dep-depinfo) #88544

Meta