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.

The biggest problem Rust has is that "no_core" is so poorly understood at this point that i doubt a comprehensive spec is even possible to explain:

1. Type inference taking into account higher ranked trait bounds

  - Slices in libcore work via the Index lang item so its like taking an index operator overload to a range lang item but the generic types in the range need to be unified with the higher ranked trait bound to eventually figure out that they are meant to be of usize.

2. Method resolution its almost a joke at this point how complicated it is in Rust.

  - The autoderef cycle sounds simple when you read this: https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/first-edition/deref-coercions.html

  - But this misses so much extra context information

3. Macro invocations there are really subtle rules on how you treat macro invocations such as this which is not documented at all https://github.com/Rust-GCC/gccrs/blob/master/gcc/rust/expan...

</rant>

Some day I personally want to write a blog post about how complicated and under spec'd Rust is, then write one about the stuff i do like it such as iterators being part of libcore so i don't need reactive extensions.

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'm personally pretty excited to see where this goes. It could be the best way for gccrs to version itself. There are some immediate aspects I am pretty interested in relation to the spec:

1. Method resolution

2. Unstable?

In particular is it going to define lang items?

3. DST's

Rust has strange things like:

```

let a:&str = "str";

let b:&str = &"str";

```

Which is valid since str is a DST. Although slices and dyn trait are DST they have more strict rules there.

4. Qualified paths

There are more subtle things like qualified paths such as this testcase which could be argued is valid https://github.com/rust-lang/rust/blob/master/src/test/ui/qu... but there was some discussion on zulip which clarifies it: https://rust-lang.zulipchat.com/#narrow/stream/122651-genera...

5. Never type

TLDR: Overall I think its important at some point to start isolating what is the language outside of what version of libcore your running.

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 :)

That's a good idea! Your comment means alot to me, thank you I put alot of work into my reports and will be trying to present them on my YouTube more regularly https://youtube.com/user/redzor812 I am really inspired by serenity os and Tim Morgan on natalie.

Hello this is Philip the author of these reports and lead for the GCC Rust project. I feel its only fair to point out that the comment you link to the author is not a "main dev for gccrs".

I wrote part of the reasons for why I am working on gccrs here: https://news.ycombinator.com/item?id=28368924

Overall I feel sad that this effort has been perceived as some kind of attack against Rustc and its community by some. This effort of mine dates back to 2014 and then I was able to get quite alot of rust working in a short time but the language changed far too much to keep up as a solo effort. Since late 2018 I restarted the effort and seriously almost started the track to develop the a gcc backend using libgccjit, it is 100% something i have considered and thought through.

I will be giving a talk on this project at LPC if you wish to hear more about my reasons please listen then https://linuxplumbersconf.org/event/11/contributions/911/

Overall 2 major question come up about GCC Rust and they are not easy to answer but here is part of my perspective on the issue.

1. Keep up with rustc language development 2. How do we handle inconsistencies in behaviour

For inconsistencies, we have stated in our FAQ that if GCC rust does not behave the same as rustc. Then it is a bug with GCC rust. So it is not fruitful for us to raise issues with rustc until we can compile and run the test suite, even though I have some edge cases worth exploring.

Keeping up with the language is a more difficult one, and it depends on your outlook. From my perspective, I think it would be ideal if Rust would version the language. For example, every new release of rustc might include:

- New unstable lang features. - new language editions (like the upcoming 2021) - Stdlib updates and stabilisations. - Features like incremental compilation. - Bug fixes. - Dependencies updates like LLVM.

This is a lot of stuff that might change, and it's only the rust compiler version that gets updated for all of this work. I can see why this is the case, and it has benefits, but I am not sure rust editions are enough.

Currently, there is little to no benefit to picking a version of Rust to target. When new features are stabilised like const generics, this means state of the art in developing robust rust crates changes overnight, pushing the whole ecosystem onto the latest version of rustc. This is neat in some ways, but I am unsure how this will play out in the long run for Rust.

For me, an alternative front-end from GCC means backing from the GCC toolchain and a way to backport Rust to older versions of GCC. This also means that custom arch vendors whose only toolchains are custom GCC/binutils can also benefit from Rust as it will be part of the upstream project.

We can also explore things like language versioning with the gcc toolchain. Or explore some of the standardization efforts which I do think is important.

Other than that, big projects are fun, (I'm a huge fan of Andreas Kling serenity-os), there is a lot of low hanging fruit for people to make their mark on the compiler. Also, I thought I understood Rust, but it's exciting when you start getting into the nitty gritty.

Hi, this is Philip, the author of these reports. Sorry if this is confusing, but these are the reports I make weekly and present to Open Source Security, Embecosm and the GCC Steering committee. As this work is all open-source, I wanted to be as open as possible about developing such an ambitious project.

Another reason is that I wish to write up some document describing how the rust-language layers up, maybe a year from now. It is not very obvious to me what is bare metal rust vs compiler magic/library magic in the rust language. With these reports and my experience down the line, this might be interesting for people to read.