Can we use proper clang instead of llvm fork what rust uses?

Hi everyone,

I was wondering can we use the official Clang instead of the LLVM fork that Rust uses?

While looking into this, I compared the commit differences between the rust-llvm version and the official llvm-project at the llvmorg-20.1.7 tag (used in Rust 1.89.0). I found that Rust's fork includes four additional commits on top of that tag:

9b1bf4cf041c [X86] Ignore NSW when DstSVT is i32 (#131755)
7341322eb32b [objcopy][MachO] Revert special handling of encryptable binaries (#144058)
44c4c3ef2205 [RelLookupTableConverter] Drop unnamed_addr for GVs in entries to avoid generating GOTPCREL relocations (#146068)
319a89e7ffe9 [AsmPrinter] Always emit global equivalents if there is non-global uses (#145648)

As far as I can see, these are all bug fixes backported from LLVM mainline.

Are there any other differences I might have missed?

Thanks in advance

What do you mean with using "proper clang"? Is this as a link driver? Or for building C dependencies? For cross language LTO?

2 Likes

Thanks for the questions, let me clarify what I meant.

By “proper Clang,” I was referring to using the upstream LLVM/Clang release (e.g., the official llvmorg-20.1.7 tag from the main llvm-project repository) instead of the Rust-specific LLVM fork.

My main concern is understanding whether it's safe and compatible to use upstream Clang/LLVM when building Rust

From my comparison, I noticed that Rust's LLVM fork includes a few backported patches on top of llvmorg-20.1.7. I'm wondering whether using vanilla Clang/LLVM would introduce any subtle issues during builds ?

In my case, I'm actually building Rust with the latest upstream LLVM tag, llvmorg-21.1.0, which already includes those four commits. So I’m trying to understand whether this setup is safe and compatible.

Specifically, I’d like to confirm:

  1. Are there any other differences between Rust’s LLVM fork and upstream LLVM that I might have missed?
  2. Is it safe to use the official upstream Clang/LLVM for building Rust ?

Note: The reason I'm looking into this is because, in our project, we already maintain a recipe for Clang/LLVM, and we also have a separate one for Rust's LLVM fork. I’ve been able to successfully build Rust using our existing upstream Clang/LLVM recipe, but the concerns I mentioned above are what I’m trying to clarify.

Ah, you were talking about LLVM, not about Clang. Rust itself has no dependency on clang as far as I know. As to your concrete question, I will let someone more knowledgeable answer.

(For cross language LTO between clang and Rust you do need to use the same version of llvm for both.)

As you see, these are bugfixes. You can build Rust against a buggy LLVM release if you can live with the consequences.

Rust is a heavy user of LLVM, and tends to rely on details that clang doesn't. This means that Rust regularly runs into issues that affect only Rust.

There's a lag between bugs being fixed and being released in LLVM, which can be blocking for Rust. Even when the bugs are fixed really quickly, the timing between LLVM and Rust releases doesn't align. Rust releases on a fixed schedule and doesn't want to ship with known bugs that don't have fixes released yet.

3 Likes

LLVM and rustc both have bugs, always. I wouldn't worry about it too much, but you can look at the patches we've added to decide if there's anything relevant to you. These days LLVM does better with backporting into their own point releases, so we don't really add much on our own.

Rust CI does test with "vanilla" LLVM (from Ubuntu's packages) for all supported versions. Some of our tests are set to ignore on older versions if we know it needs a later fix, but otherwise everything is ensured to pass.

5 Likes

Rust supports building against multiple LLVM versions:

  • Tip-of-tree for the current LLVM development branch is usually supported within a few days. PRs for such fixes are tagged with llvm-main.
  • The latest released major version is always supported.
  • The one or two preceding major versions are usually supported.
2 Likes