This comment confuses me.

> In August 2012, the GCC steering committee announced that GCC now uses C++ as its implementation language.[57] This means that to build GCC from sources, a C++ compiler is required that understands ISO/IEC C++03 standard. > On May 18, 2020, GCC moved away from ISO/IEC C++03 standard to ISO/IEC C++11 standard (i.e. needed to compile, bootstrap, the compiler itself; by default it however compiles later versions of C++).[58]

So for the past >10 years, gcc and clang have both had a C++ dependency. What is unique about LLVM/Clang here?

If I understand what you’re considering, it’s that the compiler itself may have been compiled from C++ sources, so dependencies in that accounting scheme derive from transitive closure.

Alternatively i consider a compiler might only be presented as a binary, with no visibility as to its own source code, so i consider in that case just a Rust program and a binary that compiles it to a native binary linking with binary object files also of unspecified source code languages.

Sorry, we’re in agreement. My reply was meant to reply to the parent claiming there’s a C++ dependency in the tool chain when building everything from source - that’s true for the Linux kernel today since building GCC requires a C++ compiler as well.

I think the assertion is based on the fact that LLVM is written in C++. Doesn’t directly introduce a C++ dependency to the kernel, but it does introduce it to the toolchain.

But rustc is a cross-compiler, you only need a C compiler for one platform and you get a Rust compiler for all platforms. And it's not like LLVM is doing anything that fundamentally prevents it from being written in Rust (see also the Cranelift backend for Rust, written in Rust). I'm still not quite sure what the concrete concern is. Can you elaborate?

Modern GCC is also primarily written in C++, and has had C++ deps since 2013:

https://github.com/gcc-mirror/gcc/blob/master/gcc/input.cc

You will need to generate code for the target which means LLVM/Clang (a C++ project) must support at the very least some amount of codegen for that target.

You can use the cranelift backend, written in Rust, if you prefer. Nothing about LLVM being the best choice by default has to do with the choice of implementation language.

Or more likely for something that needs to be high performance mrustc, but you obviously have to be careful there.

mrustc is written in C++, so I don't see how it's a counter to what the parent is proposing. I also don't know anything about mrustc's performance characteristics, I didn't think performance was a goal, but it's also been a while since I've checked in on it.

Oh right, I don't even know if there's a C compiler that's not written in C++ that can compile the output of mrustc anyway, so there's that.