philberty

No core _is_ the Rust language, libcore is just a library which adds the "Rust abstractions" so you can actually write a for loop or create a slice or deref, add or anything else.

Libcore just gets compiled like any other rust crate just it does not have access to abstractions.

For example, you can still write C code without libc because C is a language libc is just a library libcore is pretty much the same. Though Rust makes alot of assumptions that libcore _should_ be there but its possible for it not to be.

This is true, I tried to make gccrs only have the AST and go from that stright to GCC GENERIC. This had a lot of problems for Rust in my opinion.

Many things in Rust are syntactic sugar and can be handled by desugaring the AST into another IR so you dont even have to think about it in other passes. The main issue for me is how complicate the type inference is.

So if i wanted to use GCC GENERIC for type resolution for this example:

``` let a; a = 123; let b:u32 = 1; a += b; ```

How do you resolve the type of 'a' you must use inference variables and then update the TREE_TYPE as you go so this means walking the tree's over and over again as type information is gathered over time on the inference variable. Using a separate IR and using id's and side tables makes all of this much much more simple for Rust.

Thanks @steveklabnik we basically have the same in gccrs:

1. AST 2. HIR 3. THIR (side-table lookups) 4. GCC Generic

We basically skip MIR in gccrs.

Its pretty sensible to have other IR's, we have many passes in gccrs simplifying things so the graph of what your working with is simpler and simpler each time.

I mean in GCC for C++ for example they use GENERIC and add a bunch of custom tree-codes such as LAMBDA_EXPR or TEMPLATE stuff for example then they keep substituting etc and finally as part of handing off to GCC middle-end it triggers the gimplification of all of these custom tree codes. So even the C++ front-end you could argue has two IR's.

I would love to do a crater run, it could be be pretty exciting since we have our cargo gccrs layer. I think once we get libcore working, we could look at no_std crates :)

We are starting to track the development progress against portions of the Rustc testsuite. Also finally got slices in! :)

I can do that. Thats a nice idea too.

Hello World :) I am working on a blog post reviewing 1 year's worth of progress which should be up some time next week.

It is indeed early to say, but the design of the compiler pipeline is very different to rustc, it is a more traditional pass based system with plenty of side table lookups. Some of the notions are similar we are using HIR but we are not using MIR, GCC's generic IR is very similar.

So we have AST->HIR->GCC-Generic->GCC

where as rustc is: AST->HIR->THIR->MIR->LLVM-IR->LLVM

Hello world :)