2. The GCC developers are interested in supporting a broad set of languages that compile to native executables, and Rust is an increasingly popular language for systems programming.
3. Whether something is "necessary" or not has never been decisive in whether or not it happens. When presented with a programming challenge, why not try it and see what comes out?
It's more insane to me that one wants the same tool to do everything rather than have different tools for different tasks.
Like should Perl be compiled with GCC just to satisfy that requirement because it's used during the kernel build? That's ridiculous!
PS. GCC stands for “GNU Compiler Collection”. All of the above is already there.
I don't think you should expect or want that.
m68k is already supported by LLVM and Rust supports it as a tier-3 target platform.
Xtensa got upstream support, but so many embedd vendors seem to want to double dip and sell build tools, so they don't upstream their llvm based build tools. Shortsighted imo. Vendors that don't charge for build tools will make it up in sales volume.
A separate Rust compiler may also uncover problems in the language or standard library design (e.g. if it's too much effort to write a Rust compiler from scratch that definitely isn't a good thing IMHO).
clang made gcc and g++ better compilers. gcc-rs can do the same and help making rustc a better compiler and Rust a better language.
For the record, I don't write Rust, because GCC has no Rust support yet. More specifically, I don't use LLVM-Specific languages due to LLVM's license and stance against GCC.
As far as I can tell, GCC is licensed under GPLv3 these days. LLVM is under a variation of the Apache License.
https://www.apache.org/licenses/GPL-compatibility.html suggests that you can use code under Apache License in a project that's under GPLv3.
So someone could take legally LLVM, change the Readme and slap a GPLv3 license on it, and have the same license as GCC? (Assuming that the exceptions that LLVM's license has aren't a problem.)
Would that fix your issues? Or what is your specific problem?
This whole exercise has a point, if and only if there's a point to insisting that GCC's license is fine, but LLVM's license ain't.
It's just a reduction. https://en.wikipedia.org/wiki/Reduction_(complexity)
If you don't have any problem with the license of LLVM in the first place, the reduction is obviously useless to you.
In other words, "If you want to go fast, go alone. If you want to go far, go together".
Can you name even one other compiler which would match those requirements? Only thing that comes to my mind is Borland, although I have no idea whether their compilers shared common backend or where they completely independent. I guess at some point Microsoft might have shared some of the parts for their .NET CLR langauges (Basic, C#, F# and managed C++/CLI ). While you could make a Rust frontend for .NET it would be somewhat pointless. Rust makes certain sacrifices in terms of ease of use, for the purpose of safe low level memory management. In a VM made for higher level garbage collected languages thats just unnecessarily complexity, without the benefits. After looking more I was also able to find thing called "Amsterdam compiler kit", but that seems more like academic exercise.
Why two separate projects -> Think of it as short term vs long term solutions. Ideally in long term the multiple implementations for programing language would be completely independent, but it takes more work. In short term it's easier to glue together existing Rust frontend with GCC backend, while still getting many of the benefits of having multiple programming language implementations.
It is not that simple, there are pros and significant cons
It's unclear to me what negatives a new, independent, Free implementation brings.
On the other hand, the positives of it seem clear: an independent, Free implementation helps establish Rust the language and differentiate the language from a specific implementation of it.