Change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --After upgrading our toolchains from to , our bootloader rust crates stopped building. Instead, the build command produced the error message . 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 <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.53 --It most recently worked on: Rust 1.53 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --The compiler did not crash or produce a backtrace. </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-stable -regression-untriaged --
Looks like a dup of
Ah, it does appear to be. We had several blocks with definitions with the same name. After merging them together so that the 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: Thank you for the heads up.
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
All declarations have the same type, everywhere (). It could be that the issues are related but not strictly the same.
Can you use the 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 ?
I've tried, but it seems as though the target we build for isn't (easily?) available that way. doesn't work, and I'm not sure how to get it to work. Any guidance?
Try this (replace the hash if needed):
Thank you, now running worked. It does seem to be the same issue as in , apart from the fact that our types are all the same.
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?
Yes, that sounds good to me! Will do, and thank you for the help
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
or anyone else in this thread know how to get the builds for Apple Silicon Macs?
my best guess is: because aarch64-apple-darwin is not a , there's no alt target built per default. You may have to build it yourself. have you a better idea?
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 and not my machine and I'm a bit lost tracing what's causing this in a large project.
Huh interesting looks like my project is now only hitting this on any good way to track down which symbols are clashing?
The code that caused the issue in the project mentioned was an that pointed to itself. Removing the unnecessary resolved the issue.

Discussion:
extern "C" LLVMValueRef LLVMRustGetOrInsertGlobal(LLVMModuleRef M, const char *Name, size_t NameLen, LLVMTypeRef Ty) { <ins> Module *Mod = unwrap(M); </ins> StringRef NameRef(Name, NameLen); <del> return wrap(unwrap(M)->getOrInsertGlobal(NameRef, unwrap(Ty))); </del> <ins> // We don't use Module::getOrInsertGlobal because that returns a Constant*, // which may either be the real GlobalVariable*, or a constant bitcast of it // if our type doesn't match the original declaration. We always want the // GlobalVariable* so we can access linkage, visibility, etc. GlobalVariable *GV = Mod->getGlobalVariable(NameRef, true); if (!GV) GV = new GlobalVariable(*Mod, unwrap(Ty), false, GlobalValue::ExternalLinkage, nullptr, NameRef); return wrap(GV); </ins> } extern "C" LLVMValueRef

<ins> // build-pass // compile-flags: --crate-type=rlib --emit=llvm-ir -Cno-prepopulate-passes // This test declares globals by the same name with different types, which // caused problems because Module::getOrInsertGlobal would return a Constant* // bitcast instead of a GlobalVariable* that could access linkage/visibility. // In alt builds with LLVM assertions this would fail: // // 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. // // In regular builds, the bad cast was UB, like "Invalid LLVMRustVisibility value!" pub mod before { #[no_mangle] pub static GLOBAL1: [u8; 1] = [1]; } pub mod inner { extern "C" { pub static GLOBAL1: u8; pub static GLOBAL2: u8; } pub fn call() { drop(unsafe { (GLOBAL1, GLOBAL2) }); } } pub mod after { #[no_mangle] pub static GLOBAL2: [u8; 1] = [2]; } </ins>

<ins> // build-pass // compile-flags: --crate-type=rlib --emit=llvm-ir -Cno-prepopulate-passes // This is a variant of issue-91050-1.rs -- see there for an explanation. pub mod before { extern "C" { pub static GLOBAL1: [u8; 1]; } pub unsafe fn do_something_with_array() -> u8 { GLOBAL1[0] } } pub mod inner { extern "C" { pub static GLOBAL1: u8; } pub unsafe fn call() -> u8 { GLOBAL1 + 42 } } </ins>