Remove rustboot from the repository.
This commit is contained in:
parent
ef75860a0a
commit
6997adf763
46 changed files with 2 additions and 37556 deletions
|
|
@ -1,16 +1,6 @@
|
|||
An informal guide to reading and working on the rustc compiler.
|
||||
==================================================================
|
||||
|
||||
First off, know that our current state of development is "bootstrapping";
|
||||
this means we've got two compilers on the go and one of them is being used
|
||||
to develop the other. Rustboot is written in ocaml and rustc in rust. The
|
||||
one you *probably* ought to be working on at present is rustc. Rustboot is
|
||||
more for historical comparison and bug-fixing whenever necessary to un-block
|
||||
development of rustc.
|
||||
|
||||
There's a document similar to this next door, then, in boot/README. The boot
|
||||
directory is where we do work on rustboot.
|
||||
|
||||
If you wish to expand on this document, or have one of the
|
||||
slightly-more-familiar authors add anything else to it, please get in touch or
|
||||
file a bug. Your concerns are probably the same as someone else's.
|
||||
|
|
@ -85,34 +75,3 @@ Control and information flow within the compiler:
|
|||
type-directed translation to LLVM-ese. When it's finished synthesizing LLVM
|
||||
values, rustc asks LLVM to write them out as a bitcode file, on which you
|
||||
can run the normal LLVM pipeline (opt, llc, as) to get an executable.
|
||||
|
||||
|
||||
Comparison with rustboot
|
||||
========================
|
||||
|
||||
Rustc is written in a more "functional" style than rustboot; each rustc pass
|
||||
tends to depend only on the AST it's given as input, which it does not mutate.
|
||||
Calculations flow from one phase to another by repeatedly rebuilding the AST
|
||||
with additional annotations.
|
||||
|
||||
Rustboot normalizes to a statement-centric AST. Rustc uses an
|
||||
expression-centric AST.
|
||||
|
||||
Rustboot generates 3-address IL into imperative buffers of coded IL quads.
|
||||
Rustc generates LLVM, an SSA-based expression IL.
|
||||
|
||||
Rustc, being attached to LLVM, generates much better code. Factor of 5
|
||||
smaller, usually. Sometimes much more.
|
||||
|
||||
Rustc preserves more of the parsed input structure. Rustboot "desugars" most
|
||||
of the input, rendering round-trip pretty-printing impossible. Error reporting
|
||||
is also better in rustc, as type names (as denoted by the user) are preserved
|
||||
throughout typechecking.
|
||||
|
||||
Rustc is not concerned with the PIC-ness of the resulting code, nor anything
|
||||
to do with encoding DWARF or x86 instructions. All this superfluous
|
||||
machine-level logic that seeped up to the translation layer in rustboot is
|
||||
pushed past LLVM into later stages of the toolchain in rustc.
|
||||
|
||||
Numerous "bad idea" idiosyncracies of the rustboot AST have been eliminated in
|
||||
rustc. In general the code is much more obvious, minimal and straightforward.
|
||||
|
|
|
|||
|
|
@ -984,9 +984,7 @@ fn parse_bottom_expr(parser p) -> @ast::expr {
|
|||
* FIXME: This is a crude approximation of the syntax-extension system,
|
||||
* for purposes of prototyping and/or hard-wiring any extensions we
|
||||
* wish to use while bootstrapping. The eventual aim is to permit
|
||||
* loading rust crates to process extensions, but this will likely
|
||||
* require a rust-based frontend, or an ocaml-FFI-based connection to
|
||||
* rust crates. At the moment we have neither.
|
||||
* loading rust crates to process extensions.
|
||||
*/
|
||||
|
||||
fn expand_syntax_ext(parser p, ast::span sp,
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue