Make LLVMRustGetOrInsertGlobal always return a GlobalVariable

[cuviper]

Module::getOrInsertGlobal returns a Constant*, which is a super
class of GlobalVariable, but if the given type doesn't match an
existing declaration, it returns a bitcast of that global instead.
This causes UB when we pass that to LLVMGetVisibility which
unconditionally casts the opaque argument to a GlobalValue*.

Instead, we can do our own get-or-insert without worrying whether
existing types match exactly. It's not relevant when we're just trying
to get/set the linkage and visibility, and if types are needed we can
bitcast or error nicely from rustc_codegen_llvm instead.

Fixes#91050, fixes#87933, fixes#87813.

[rust-highfive]

r? @matthewjasper

(rust-highfive has picked a reviewer for you, use r? to override)

[cuviper]

cc @datdenkikniet@haraldh -- if you could confirm that this fixes your bugs, that would be great. I'll start a build:

@bors try

[bors]

⌛ Trying commit 023cc96 with merge 04339b3fab9c798bce7fed137e7f5ac81ab52509...

[cuviper]

cc @hellow554 was also testing those bugs.

[bors]

☀️ Try build successful - checks-actions
Build commit: 04339b3fab9c798bce7fed137e7f5ac81ab52509 (04339b3fab9c798bce7fed137e7f5ac81ab52509)

[nagisa]

Ah, actually, I do have a concern about what would happen with the code of the following shape (i.e. actual uses of the differently typed globals exist):

pubmod before {extern"C"{pubstaticGLOBAL1:[u8;1];}pubunsafefndo_something_with_array() -> u8{GLOBAL1[0]}}pubmod inner {extern"C"{pubstaticGLOBAL1:u8;}pubunsafefncall() -> u8{GLOBAL1 + 42}}

can we add a test like that too?

---

As I was busy coming up with the test case I built a compiler with this change, and indeed this case is problematic, building it with the following flags produces:

$ rustc test.rs --crate-type=rlib --emit=llvm-ir -Cno-prepopulate-passes
LLVM ERROR: Invalid LLVMRustVisibility value!

---

@bors r- for now

[cuviper]

As I was busy coming up with the test case I built a compiler with this change, and indeed this case is problematic, building it with the following flags produces:

$ rustc test.rs --crate-type=rlib --emit=llvm-ir -Cno-prepopulate-passes
LLVM ERROR: Invalid LLVMRustVisibility value!

Are you sure your rustc command used my change? I can reproduce that error with nightly, but my local build works.

edit: it's also fine with the try build 04339b3fab9c798bce7fed137e7f5ac81ab52509 above.

[cuviper]

@nagisa I added your test variant.

[nagisa]

Are you sure your rustc command used my change?

/me facepalms. rustc was the rustup rustc and not ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc.

@bors r+ Thanks!

[bors]

📌 Commit 3b2cfa5 has been approved by nagisa

[cuviper]

Moved the tests to appease tidy.

@bors r=nagisa

[bors]

📌 Commit 3aa1954 has been approved by nagisa

[datdenkikniet]

A little late to the party perhaps, but this PR does indeed seem to fix the issues we faced in #87933

It's slightly difficult to tell because the error was spurious, but I've cleaned/built about 10 times now and it hasn't produced an error once, which it did do relatively consistently before these changes.

[glandium]

Is it too late to get this in 1.57?

[cuviper]

It is very late for 1.57, but possibly not too late -- @Mark-Simulacrum what do you think?

[nagisa]

Given that it is fixing a relatively longstanding regression I would personally prefer this to ride the 🚆.

[Mark-Simulacrum]

If it's nominated/accepted by beta backport quite soon (next ~72 hours), we can get it in, but not otherwise. I have no strong opinion or sense of the exact possibility for problems caused by this patch, though.

[cuviper]

I'm OK with @nagisa's opinion to let it wait through the normal release process, but I might still backport in Fedora for its bug.