-Clink-dead-code causes `extern crate failure_derive` to not be found on Windows

[KarelPeeters]

For context, this issue comes up when trying to collect code coverage metrics for projects that depend on certain crates. It was previously reported about a year ago here intellij-rust/intellij-rust#6325 and here mozilla/grcov#502, but the root issue is in rustc. What follows is a minimal reproduction.

For some reason a crate that depends on failure fails to compile when -Clink-dead-code is set, but only on Windows. It works fine when RUSTFLAGS is empty, or on Linux.

To reproduce, run the following commands in Powershell on Windows, in an empty folder:

cargo init
echo 'failure="0.1.8"' >> Cargo.toml
$env:RUSTFLAGS="-Clink-dead-code"
cargo build

The error printed is:

error[E0463]: can't find crate for `failure_derive`
  --> C:\Users\Karel\.cargo\registry\src\github.com-1ecc6299db9ec823\failure-0.1.8\src\lib.rs:56:1
   |
56 | extern crate failure_derive;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate

For more information about this error, try `rustc --explain E0463`.

Running cargo clean followed by cargo build -vv has this output: https://gist.githubusercontent.com/KarelPeeters/e5436e18e618dc23a55b9e77ed3c9279/raw/1f4bc3bc76a8e4e52175138a01ee51a1046c4387/gistfile1.txt

This doesn't happen for most crates, I have about 20 dependencies and this issue only comes up with failure/failure_derive for me. In the first issue someone else had the same problem with const_fn = "0.4.2", but I cannot reproduce that.

I tried my own issue on today's stable rustc 1.55.0 (c8dfcfe04 2021-09-06) and nightly rustc 1.58.0-nightly (bd41e09da 2021-10-18) and both Windows and Linux, and this happens for both versions on Windows and for neither version on Linux.

[ehuss]

Hm, that's strange! As a workaround, you can use the --target flag. Without the --target flag, RUSTFLAGS get applied to proc-macros and build scripts. For some reason, -Clink-dead-code is corrupting the proc-macro.

The underlying error is: no metadata found: failed to decompress metadata while loading the failure_derive DLL. Unfortunately the compression error isn't logged. If I get a chance, I'll try to take a closer look.

[ehuss]

I took a closer look. For some reason, the linker is expanding the .rustc section in the DLL with a bunch of 0 bytes. On my system, for the failure_derive DLL, the metadata data is 2114 bytes compressed, but with -Clink-dead-code, the section has 678 extra 0 bytes tacked onto the end. Otherwise, the first 2114 bytes look correct. I don't have an explanation of why that happens, though.

[chylex]

Hm, that's strange! As a workaround, you can use the --target flag.

How should the --target flag be used for the workaround? Do you mean switching from x86_64-pc-windows-msvc to x86_64-pc-windows-gnu?

[ehuss]

No, just --target x86_64-pc-windows-msvc. That changes cargo to behave differently (it won't set rustflags for host-only things like proc macros).

[conqp]

Not sure whether this is related, but I just tried to test one of my projects with Coverage on Windows 10 x86_64 resulting in this error message:

error[E0786]: found invalid metadata files for crate `proc_macro_error_attr`
   --> C:\Users\Richard Neumann\.cargo\registry\src\github.com-1ecc6299db9ec823\proc-macro-error-1.0.4\src\lib.rs:284:9
    |
284 | pub use proc_macro_error_attr::proc_macro_error;
    |         ^^^^^^^^^^^^^^^^^^^^^
    |
    = note: failed to decompress metadata: \\?\C:\Users\Richard Neumann\Documents\GitHub\rucman\target\debug\deps\proc_macro_error_attr-e65d70350badad02.dll

On my Linux machine, however, the test runs fine.