Inconsistent behavior between check and build when handling duplicate #[no_mangle] static values

[zack-emmert]

(if this issue is better suited to rust-lang/rust, please let me know and I'll post it there)

Problem
cargo check and cargo build behave differently when handling two identically-named #[no_mangle] static values defined in different modules. cargo check incorrectly succeeds without detecting any issues, while cargo build correctly throws a "symbol has already been defined" error.

Steps

1. Copy the snippet below these instructions into a new project
2. Execute cargo check, observe incorrect success
3. Execute cargo build, observe correct compiler error

mod other {
    #[no_mangle]
    pub static ITSBROKEN: u8 = 0;
}

#[no_mangle]
pub static ITSBROKEN: u8 = 0;

Notes

Output of cargo version: cargo 1.36.0 (c4fcfb725 2019-05-15)
Target: x86_64-unknown-linux-gnu
Linux distribution: Fedora 30 (fully updated)

[ehuss]

I went ahead and transferred this to rust-lang/rust.

I think this is a pretty well-known issue where the metadata step does not perform all the same work as codegen/linking. #49292 is one of the issues that discusses it.

[zack-emmert]

In this particular case, wouldn't it be possible to cache a list of no-mangle'd symbols from dependencies at build time, then have cargo check keep track of every no-mangle'd symbol in the current crate, and error if there are any duplicates?

[Enselic]

Triage: As codified in https://rust-lang.github.io/rfcs/3477-cargo-check-lang-policy.html, cargo check and cargo build are not guaranteed to give the same errors.

While in theory the behavior of the linker can be simulated before actually invoking the linker (especially in simple cases like this), it is by my estimation not sensible, because it would significantly increase the amount of compiler code to write and maintain, and the benefit would be small.

So I'll go ahead and close this as won't fix. If anyone disagrees with the close, of course feel free to re-open.