Solving the bootstrap problem


#1

Hello,

I talked briefly with Graydon Hoare about Rust and C++ at Mozilla Summit 2010 in Whistler, Canada, and since then I keep an eye on the project. Recently I started to read seriously about Rust and I made a plan for my possible contribution to Rust. I would like feedback on the feasibility of the plan and if there is an implementation and it is successful, would the Rust project be interested in using it :smiley:

urust2c: Unsafe Rust transpiler to C

The sole purpose of the transpiler is to serve as stage0 in bootstrapping Rust in platforms that has only C compiler. Everything that doesn’t serve this purpose is cut off.

(Lack of) Features:

  • No borrow checker and also other checks. urust2c will be more unsafe than unsafe {}.
  • No descriptive error messages. On the first error, urust2c will just panic with showing source location and urust2c source location where the panic was triggered.
  • No platform-specific generated code. Use glib in generated code and the transpiler itself. Software requirements for urust2c would be https://wiki.gnome.org/Projects/GLib/CompilerRequirements
  • Human-readable generated code. urust2c will need to have pre-generated C source code for parts of libstd and possibly other libs.
  • No compatibility between urust2c and rustc object files.

Let’s discuss this approach to solving the bootstrapping problem raised in https://groups.google.com/forum/#!topic/mozilla.dev.platform/Pi981js7lFA


#2

This has come up a couple of times before. Recent examples:

For my part I’m skeptical; yes, you can get by without borrowck or dropck, but you still need typeck because it controls overloading and name resolution, and Rust has return type overloading so you can’t cheat with a dynamically typed implementation. Very interested to see what people can come up with though.


#3

This may be a stupid question, but is it possible to interpret (or compile to C) LLVM intermediate representation? Does this Low Level Virtual Machine exist?


#4

Yes. http://llvm.org/docs/CommandGuide/lli.html


#5

It seems to me that LLVM bitcode would be just another form of snapshot, especially since it’s still target-specific, so it doesn’t really solve the problem.


#6

This is very similar to the approach I’m doing for my project ‘mrustc’ (http://github.com/thepowersgang/mrustc) - I may eventually get to the point when I can generate readable C code, but for now I’m still slowly working through the compiler stages.


#7

На 21.03.2016 в 02:06, Mutabah / John Hodge написа:

This is very similar to the approach I’m doing for my project ‘mrustc’ (http://github.com/thepowersgang/mrustc) - I may eventually get to the point when I can generate readable C code, but for now I’m still slowly working through the compiler stages.

Oh, so there are projects like this. And C++11 is definately nicer than C+glib :slight_smile:


#8

Even better, we can interpret MIR: https://github.com/tsion/miri


#9

I would not like to have 2 incompatible Rust dialects.

Is the lack of features only to make the analysis phase of your compiler easier? Maybe you could reuse the existing rust compiler as a first pass to check the code validity, before running your own code generator.


#10

В 08:26 +0000 на 21.03.2016 (пн), ker написа:

matklad: is it possible to interpret (or compile to C) LLVM intermediate representation?

Even better, we can interpret MIR: https://github.com/tsion/miri

Generating C/C++ from some intermediate representation definitely needs to be explored. The big question is if this would be acceptable by Debian, Fedora, Tor (reproducible builds) and others.


#11

В 08:52 +0000 на 21.03.2016 (пн), Uther написа:

Uther March 21 I would not like to have 2 incompatible Rust dialects.

Is the lack of features only to make the analysis phase of your compiler easier? Maybe you could reuse the existing rust compiler as a first pass to check the code validity, before running your own code generator.

Lack of these features eases greatly development and future maintenance of the project while providing stage0 rustc for any platform supported by glib. urust2c is not meant for any other purpose so it is OK. The "dialect" we are talking about is like having everything inside unsafe {}.