Call for help implementing an independent Rust frontend for GCC

community
1

Starting a new thread to increase visibility, since the previous GCC thread is quite old.

A friend of mine (Luke Kenneth Casson Leighton) has been talking to Richard Stallman about the need for a Rust frontend for GCC to allow Rust to replace C in more places, such as system software.

To allow some types of safety-critical software to be written in Rust, the GCC frontend would need to be an independent implementation of Rust, since the relevant specs require multiple independent implementations (so just attaching GCC as a new backend for rustc wouldn't work).

I'm aware of at least one rust frontend (gccrs by @redbrain), however it is very early code and is based on Rust before Rust 1.0, so is quite out-of-date.

I am also aware that Rust doesn't have a spec other than the rustc source code, which will definitely need to change, which I think is being worked on.

Is anyone interested in working on implementing a Rust frontend for GCC? I currently have other projects (libre-riscv GPU & Kazan Vulkan driver) that I'm busy with, so I most likely wouldn't be able to help very much, but I can get interested people in touch with Stallman.

Jacob Lifshay

26 Likes
2

As far as I know, The Other Implementation is mrustc, a Rust->C compiler written in C++. If you want a starting point other than rustc, you should probably go with that.

2 Likes
3

Would the goal be to create a Rust compiler written in Rust using a Rust front-end to GCC or would it be a Rust Compiler written in C?

Would a goal be for the GCC version to be able to compile the existing Rust compiler and for the current Rust compiler to be able to compile the GCC Rust Front-End version of the Rust compiler? That would seem like an interesting thing to do? Would deterministic/reproducible builds of both be a goal?

4 Likes
4

The goal is for the GNU Compiler Collection to have a peer level front end to the gfortran frontend, gcc frontend, g++ frontend and all other frontends.

The goal is definitely not to have a compiler written in rust that compiles rust code [edit: unless there is an acceptable bootstrap process, and the final compiler produces GNU assembly output that compiles with GNU gas]

The goal is definitely not to have a hard critical dependence on LLVM.

The goal is to have code added, written in c, to the GNU Compiler Collection, which may be found here https://gcc.gnu.org such that developers who are used to gcc may compile rust programs and link them against object files using binutils ld.

Exactly as redbrain did, just brought up to date.

As the GNU Compiler Collection, known slightly misleadingly as gcc (confused often with gcc's clang frontend), already has this feature, the answer would automatically be "yes". As in: if it was not, it would be considered an eyebrow raising bug.emphasized text

5

It would, not least because gcc contains bootstrapping cross verification that is performed in multiple steps.

Having a way to both bootstrap the current rust compiler and be able to cross verify would be extremely useful.

However given that the GCC rustlang implementation should, like all gcc's code, be written in c (so that it may be bootstrap compiled even with the most godawful braindead proprietary c compilers the commercial world has ever produced - HPUX, AIX, SunOS 4.1.3 shudder), rustlang-llvm would not be able to compile it however clang-llvm probably could. This however would be out of scope.

6

I may be wrong, but as far as I know, the Ada compiler GNAT is part of GCC and is written in Ada.

And version 9.1 added support for D, sharing the front-end with the Digital Mars D compiler written in D.

1 Like
7

Yes, the GCC Ada compiler is written partially in Ada. Additionally, the D, Go, and Fortran compilers also have portions written in their respective languages.

Personally, I think it's just fine for the GCC Rust frontend to be written in Rust, as long as it can be cross-compiled to whatever system needs to run it.

2 Likes
8

I've personally never worked on compilers per se, but, I would definitely be interested in contributing to this effort if for no other reason than to have another implementation of Rust so that the Rust ecosystem can grow.

9

How "independent" do the GCC and rustc front-ends need to be? Can they use common libraries (whether in C/++ or in Rust)? Can they have any other code in common?

Since the Rust language is still evolving, as is the implementing compiler technology (e.g., lexically-scoped lifetimes -> NLL -> Polonius), with a new release every six weeks, how many months or years of lag behind rustc is acceptable for the "independent" GCC implementation?

13 Likes
11

I am interested in this effort. On the other hand, @lkcl,

However given that the GCC rustlang implementation should, like all gcc's code, be written in c (so that it may be bootstrap compiled even with the most godawful braindead proprietary c compilers the commercial world has ever produced - HPUX, AIX, SunOS 4.1.3 shudder)

This is not true. GCC's Go frontend, for example, is written in GCC dialect of C++. Bootstrap works like this: godawful C compilers first compile C and C++ portion of GCC. Rest of GCC is compiled with this GCC, not godawful C compilers. I believe GCC's Rust frontend should do the same and should not concern itself with compat with godawful C compilers. Compiling Rust is difficult enough without such misery.

1 Like
12

Ok, yes, as long as you get into the existing gcc front-ends, you're fine. So hypothetically the rustlang compiler could be written in gfortran, because gcc happily compiles that up from scratch. That would be a bundle of fun.

Yes you have a better handle on (used more accurate words) how gcc bootstrapping works.

So, correction: either gcc or g++ could be used, thank you for spotting that, sanxiyn.

Jacob: if the frontend in gcc is written in rustlang, how do you get to bootstrap to gcc being able to compile that rustlang frontend in order to compile the frontend? (hint: answers do NOT involve use of rustlang-llvm :slight_smile: )

It would be necessary to have a minimal subset rustlang compiler, written in c/c++, which could at least be used to compile a second stage compiler written ONLY in the subset of rust but providing full functionality, which FINALLY compiles the actual compiler which supports the FULL functionality of rustlang, wouldn't it?

This is the process that sanxiyn is referring to, and it's pretty awkward, but feasible.

To that end, actually, now that I think about it, there is no reason why redbrain's original work should not be considered the first stage bootstrap compiler!

It would mean that the second stage in the 3 stage bootstrap process could be written in rustlang, it would just have to be in the pre 1.0 rustlang, which may not appeal to a lot of people.

The final third stage could be written in the latest version of rustlang and be capable of both compiling itself and also the current rustlang-llvm compiler.

Later iterations could greatly improve on this.

The nice thing is that once crate is compilable it will be possible to start grabbing libraries and source that could accelerate the process of getting up and running. However a caveat is that great care needs to be taken to minimise the dependencies during the bootstrap process, and a full license audit would be needed on any libraries, if they were to become effectively critical build or runtime dependencies of gcc-rustlang.

Great feedback, very encouraging.

L.

13

Yes absolutely not, there was a misunderstanding if you believed I was suggesting such insanity!

Yes of course. The only caveat is that the FSF will be unhappy with nonfree software licenses if they are hard critical dependencies. Nonfree includes BSD "Advertising" clauses (which pressurise applications writers to promote the developer during application startup). That sort of thing.

Also I would be wary of including "autodownload" capability as a hard bootstrap dependency, because the typical GNU Users, whose needs and perspectives have to be respected, are simply not going to accept arbitrarily downloaded code from unverified sources that soneone whom they do not know has said "this is fine to autodownload, trust me". Look up the recent attacks on npm, ruby gems, and archlinux, if you are not familiar with this issue.

Bottom line is, the actual bootstrap process really should list manual source dependencies (perhaps including a Makefile or setup.sh with wgets for convenience).

However once the final-stage compiler is up and is capable of compiling itself, it should definitely then be used to compile crate, so that users can get started straight away into the standard rust community.

14

@lkcl mrustc could be hypothetically used to compile the initial version of the rust frontend when bootstrapping, it's written in C++ and supports a much more recent version of rust. it would only be good for bootstrapping though because it assumes the rust code is correct and doesn't do complete type/lifetime/etc. checking (from what I recall).

2 Likes
15

That's fantastic to hear, gbutler69. Compilers are obtuse and also a lot of fun, there is something deeply satisfying about the art of efficiently preserving meaning and intent of what a human wants to happen and turning it into what a computer can actually do.

1 Like
16

Yes, of course. Ha! I will have a word with Dr Stallman, check its license, and see if it would be an acceptable approach.

It might turn out that there is less to do than first seems.

The primary thing is that the final compiler needs to be able to produce assembly files that can be compiled with GNU binutils gas and linked with GNU binutils ld, i.e do not require parts of llvm source code to get to a fully working binary. (The license under which LLVM is developed is not acceptable to the FSF, and build and runtime dependencies on LLVM will be rejected)

Conforming to ELF interoperability in particular being able to link with object files that were compiled by gcc and g++ will also be critical.

Linking to rust crates, so that users of the gcc compiler are not isolated from the rest of the rust community, will also be a necessary requirement. At the very least (a backup option) they should be able to get the source code using cargo and have to recompile everything, but there should be no loss of functionality or major penalty for doing so.

One last issue: the FSF asks people to assign copyright. This so that there is a central single Foundation in charge of pursuing Copyright violations. Credit is still given and acknowledged.

17

I think, if memory serves correctly, that mrustc is able to fully compile the Rust compiler from around 1.19 (or something like that). That could be used as the starting point as mrustc is able to be compiled by GCC to my knowledge already.

18

Was wondering if you could provide links to why the FSF doesn't like a compiler build-time dependency on LLVM, since LLVM has switched to the Apache 2.0 license, which the FSF recommends for non-copyleft software. Note that, if rustc is used for initial bootstrapping, once there is a working gcc rust compiler, the gcc rust compiler wouldn't need LLVM.

1 Like
19

Yes, but, GCC is intended to be 100% "Copyleft" (so-to-speak). Also, it would be better for the ecosystem to have a 100% completely independent implementation that shared almost nothing (especially something as big as LLVM) if for no other reason than to prove out the concepts more fully and to provide independent verification for security and compliance purposes.

EDIT: corrected my egregious typos above! Blech!

2 Likes
20

Exactly. It is perfect as the 2nd phase bootstrap compiler, to get the (proposed, likely) final rustlang compiler - written in rustlang - up and running.

However.... where that goes slightly awry is if mrustc's sole target is... llvm-ir, or if it assumes that anything from llvm is a compile dependency.

I just checked the README: mrustc is actually a language translator, into c! Excellent!

So yes you are right, gbutler69, there is no problem, there, in using it as the intermediary. The nice thing there is that if you personally prefer to use clang-llvm for the bootstrap you can.

So yes! mrustc could be used, and the final compiler written in rust. Also, because mrustc does not have proper error checking, the current rustlang-llvm compiler could be used for development, to make sure the final compiler is correct, however that really should be used as well as mrustc, not instead of! Otherwise there is the risk of writing something that is incompatible with mrustc, which defeats the exercise entirely :slight_smile:

1 Like
21

I will check with Dr Stallman. In the meantime, think about it from the perspective of both "self reliance" as well as the actual number and size of dependencies, as well as what it implies. Some GNU Users actually do source code audits. Having LLVM - all of it - as a critical build dependency is not reasonable.

Similar logic went into python's use of autoconf. Some naive well intentioned person "ported" python's build process to scons. Guess what scons is written in? facepalm :slight_smile:

1 Like