-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
First round of LLVM 6.0.0 compatibility #47710
Conversation
LLVM has since removed the `CodeModel::Default` enum value in favor of an `Optional` implementationg throughout LLVM. Let's mirror the same change in Rust and update the various bindings we call accordingly. Removed in llvm-mirror/llvm@9aafb854c
Just bog-standard compile error fixed by adding some new header files
Looks like they did some refactoring of flags in the backend and this should catch us up! The "unsafe algebra" boolean has been split into a number of boolean flags for various operations, and this updates to use the `setFast` function which should hopefully have the same behavior as before. This was updated in llvm-mirror/llvm@00e900afd
It looks like LLVM also removed it in llvm-mirror/llvm@f45adc29d in favor of the name "GNU64". This was added in the thought that we'd need such a variant when adding mips64 support but we ended up not needing it! For now let's just removing the various support on the Rust side of things.
Updated in llvm-mirror/llvm@203c90ba this function now just returns an `Error`, so this updates the C++ bindings accordingly
The comment for why cloning exists doesn't actually apply for wasm today and apparently cloning is causing subtle bugs in LLVM, so let's just avoid it altogether. More specifically after we emit the assembly for the wasm target we don't actually use the module again, so there's no need to keep both around. This seemed to be causing some scary verifier assertions in LLVM which seemed to be uncovered by presumably (?) buggy behavior. Let's just avoid it for now and make the wasm target slightly more lean in the process.
(rust_highfive has picked a reviewer for you, use r? to override) |
📌 Commit cf5b520 has been approved by |
💡 This pull request was already approved, no need to approve it again.
|
📌 Commit cf5b520 has been approved by |
Looks like the clang with 16.04 fails to compile LLVM 6, but it looks like clang in 18.04 can indeed compile LLVM 6.
cf5b520
to
e9a6499
Compare
@bors: r=nikomatsakis |
📌 Commit e9a6499 has been approved by |
…atsakis First round of LLVM 6.0.0 compatibility This includes a number of commits for the first round of upgrading to LLVM 6. There are still [lingering bugs](rust-lang#47683) but I believe all of this will nonetheless be necessary!
@bors: r- nah that was accidentally. When including this in #47748 I've removed the submodule and if that doesn't land I'll update this PR |
This includes a number of commits for the first round of upgrading to LLVM 6. There are still lingering bugs but I believe all of this will nonetheless be necessary!