Invalid LLVMRustVisibility value! error on cargo build after upgrading from 1.53.0 to 1.54.0

[datdenkikniet]

After upgrading our toolchains from 1.53.0 to 1.54.0, our bootloader rust crates stopped building.

Instead, the build command produced the error message LLVM ERROR: Invalid LLVMRustVisibility value!.

Code

As these are a closed-source projects I cannot share any code publicly, but it can be shared privately if necessary.

I expected to see this happen: the build to succeed

Instead, this happened: the build failed

Version it worked on

It most recently worked on: Rust 1.53

Version with regression

rustc --version --verbose:

rustc 1.54.0 (a178d0322 2021-07-26)
binary: rustc
commit-hash: a178d0322ce20e33eac124758e837cbd80a6f633
commit-date: 2021-07-26
host: x86_64-unknown-linux-gnu
release: 1.54.0
LLVM version: 12.0.1

Backtrace

The compiler did not crash or produce a backtrace.

[hellow554]

Looks like a dup of #87813

[datdenkikniet]

Ah, it does appear to be. We had several extern "C" blocks with definitions with the same name. After merging them together so that the extern "C" variables only occurred once the projects started compiling again.

The sections looked as follows, if that helps. They were repeated a few times in different scopes:

extern "C" {
    static mut __bootloader_magic_value__: u32;
    static mut __firmware_start__: u32;
}

Thank you for the heads up.

[hellow554]

You may search whether you have declarations that have the same name, but a different type. I was only able to reproduce the error with that constraint, see #87813 (comment)

[datdenkikniet]

All declarations have the same type, everywhere (u32). It could be that the issues are related but not strictly the same.

[hellow554]

Can you use the https://github.com/kennytm/rustup-toolchain-install-master project to get a "-alt" nightly (which has LLVM assertions enabled) and try to compile your code with it. Does it give you the same result as #87813 (comment) ?

[datdenkikniet]

I've tried, but it seems as though the target we build for isn't (easily?) available that way.

rustup-toolchain-install-master -a -t thumbv7em-none-eabihf doesn't work, and I'm not sure how to get it to work. Any guidance?

[hellow554]

Try this (replace the hash if needed):

rustup-toolchain-install-master -a -c rust-src -f
cargo +d488de82f30fd1dcb0220d57498638596622394e-alt build --target thumbv7em-none-eabihf -Zbuild-std

[datdenkikniet]

Thank you, now running cargo build worked.

It does seem to be the same issue as in #87813 (comment), apart from the fact that our types are all the same.

rustc: /checkout/src/llvm-project/llvm/include/llvm/Support/Casting.h:269: typename cast_retty<X, Y *>::ret_type llvm::cast(Y *) [X = llvm::GlobalValue, Y = llvm::Value]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.

[hellow554]

Ok, I think then we should leave this issue open until a fix is available. I would suggest that you branch the current work to have it later available for testing.
If a fix is merged, I hopefully will remember this and ping you again to test it with that nightly again. Is that feasible for you?

[datdenkikniet]

Yes, that sounds good to me! Will do, and thank you for the help

[apiraino]

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-high

[deg4uss3r]

@hellow554 or anyone else in this thread know how to get the -alt builds for Apple Silicon Macs?

❯ rustup-toolchain-install-master -a -c rust-src -f
fetching master commit hash...
detecting the channel of the `8f8092cc32ec171becef8ceacec7dbb06c5d7d7e` toolchain...
downloading <https://ci-artifacts.rust-lang.org/rustc-builds-alt/8f8092cc32ec171becef8ceacec7dbb06c5d7d7e/rustc-nightly-aarch64-apple-darwin.tar.xz>...
error: missing component `rustc` on toolchain `8f8092cc32ec171becef8ceacec7dbb06c5d7d7e` on channel `nightly` for target `aarch64-apple-darwin`

[hellow554]

@deg4uss3r my best guess is: because aarch64-apple-darwin is not a tier1 platform, there's no alt target built per default. You may have to build it yourself.

@apiraino have you a better idea?

[deg4uss3r]

I don't mind building myself was just hoping I didn't have to!

edit: I built it myself no problems there, was curious if there was a way to get a line or function name easily that is causing the clash? I'm seeing this only on my aarch64-apple-darwin and not my x86_64-apple-darwin machine and I'm a bit lost tracing what's causing this in a large project.

[deg4uss3r]

Huh interesting looks like my project is now only hitting this on cargo test any good way to track down which symbols are clashing?

[kjvalencik]

The code that caused the issue in the project @deg4uss3r mentioned was an extern "C" that pointed to itself.

    #[used]
    #[link_section = "__TEXT,__asar_integrity"]
    #[no_mangle]
    static _EMBED_ASAR_INTEGRITY: [u8; 4] = *b"1234";

    extern "C" {
        #[link_name = "_EMBED_ASAR_INTEGRITY"]
        static START: [u8; 0];
    }

Removing the unnecessary extern "C" resolved the issue.