Join forces

[michalfita]

Please join forces with https://github.com/sapir/gcc-rust and don't try to do that by yourself. We need one good Rust frontend for GCC not multiple projects that both fail.

Thank you.

[SimplyTheOther]

Please join forces with https://github.com/sapir/gcc-rust and don't try to do that by yourself. We need one good Rust frontend for GCC not multiple projects that both fail.

Thank you.

The projects seem to have completely different approaches to implementing a Rust front end. gcc-rust looks like it’s a wrapper for rustc itself to be used in GCC (and is written in Rust itself and so suffers the same bootstrapping problems as the current rustc, as well as the “trusting trust” issue) while gccrs is a full alternative implementation written in C++. I don’t think that there would be much overlap between the actual code required with each project as they currently stand.

[michalfita]

What about joining forces with with https://github.com/thepowersgang/mrustc some way?

(I'd help myself, but I'm not a compiler type of guy, too much other work to do - however grustc would be huge benefit at convincing employers to use Rust 😄)

[philberty]

Hi thank you for pointing this out

I dropped working on this project for a few years because for 2 reasons:

1. How on earth do i approach this and why.
2. Personal Life job was too busy to do anything

It has taken along time to decide what direction i wanted to go given the size of the task.

Option 1 - Do what @sapir doing by reusing MIR from rust

     - Pros:
       a. No need to implement Lexer or Parser
       b. No need to implement analysis
       c. Get the same diagnostics
       d. unifyies the implementation to simply be a new backend

     - Con:
       a. Relies on rust
       b. possible license issues

Option 2 - Use rust GCC bindings to reuse GCC JIT interface ontop of the rust compiler

     - Pros:
       a. No need to implement Lexer or Parser
       b. No need to implement analysis
       c. Get the same diagnostics
       d. unifyies the implementation to simply be a new backend
       e. Gives rise of possibly doing full JIT on the fly

     - Cons:
       a. Lacks clarity of direction

Option 3 - Full GCC C++ implemtation

     - Pros:
       a. Clear vision to have an independant c++ implementation
       b. Can follow the gccgo pattern for making it independant front-end code to retarget GCC or LLVM or Mono or JVM
       c. No license issues it is a full reimplemtation
     - Cons:
       a. Huge task

There is no clear winner in terms of a pragmatic goal of implemting rust on GCC as each of them will do it and in a contest of fastest/reliable to the post it will be Option 1 and hats of to @sapir this is looks like its shaping up very well and i wish him all the sucess.

Option 3 appeals to me as there is a vision of what could be possible with this front-end code which exicites me. Given the size of the task i have taken the last few years to decide this is what my open-source focus will be for at least the next 2 years. I hope i can stick to this goal to see where i get to with it as i feel its very much a worthwhile goal for rust.

[NalaGinrut]

@redbrain It's so sad to hear this project was stopped. What if I submit some patches in my casual time? Do you think it's fine to maintain it and accept the patches, or do you prefer another fork?

[ArneBab]

Is there a place where you provide updates (i.e. small news snippets)?

(I’m happy to hear that you’re working on this again!)

[NalaGinrut]

I've made little research around GCC frontend and the current Rust upstream implementation. I'm interested in making some progress in Rust on GCC. But I have to finish another compiler project of mine first. So it may not be very soon to show something. Anyway, I hope we can use Rust seriously with GCC.
BTW, I prefer option-3.

[philberty]

Is there a place where you provide updates (i.e. small news snippets)?

(I’m happy to hear that you’re working on this again!)

Thanks for this i have several patches in progress to get this to a working state where people can jump in. As for news i have just created a blog over at:

https://thephilbert.io/

nothing there yet but i will be putting up some stuff next week on the status and my plan.

[ArneBab]

You’re awesome — thank you!

[SimplyTheOther]

I've written a fully-operational and working lexer, parser, and AST for a potential Rust GCC frontend that I can provide as patches. The code has been targeted against stable Rust as of December 2019 and is hand-coded recursive-descent (as opposed to generated). It doesn't yet complete macro expansion, name resolution, type checking, conversion to GCC IR, etc., but should be useful as a starting point if you haven't already written the patches. It's at https://github.com/SimplyTheOther/gccrs/tree/master/gcc/rust/test3 if anyone wants to look at it.

[philberty]

@SimplyTheOther Thanks for this, the work looks really good here. I reckon it would be a fairly hard project to get that merged into my stuff so how about i do it. I will rebase from your work to just the test3 folder as the front-end and merge in my work so you still have the git history of your work

[philberty]

@SimplyTheOther I have completed a rebase with your work into this branch https://github.com/philberty/gccrs/tree/simply-philbert-rebase/gcc/rust

If your happy with me using this as a base i would like to push to master and continue my work ontop of this. We could also change this into an organisation so you have ownership too.

[NalaGinrut]

@SimplyTheOther Thanks for the work! I've taken a look at your code. Now that you've finished the time-consuming parser part, I'd like to continue the work based on your existing code. And if you create an organization, I think it's better to choose a branch-based model, say, lock the master branch, and allow members to create branches, so that the contributions can be reviewed in PR.

[SimplyTheOther]

@philberty Using this as a base would be absolutely great. I'd be happy to contribute further too or answer any questions about design and implementation choices if you have any.

@NalaGinrut No problem. However, I'm not so sure that the parser is the time-consuming part - I imagine the type checking (since rust heavily uses type inference) and name resolution, as well as more advanced stuff like borrow checking if planned to be implemented, would take up quite a lot of time too.

[NalaGinrut]

@SimplyTheOther Agreed, type checking would be the hard work. I think you've roughly finished the architecture without filling in some functions. But I need time to understand your idea in the code. To organize a community efficiently, maybe we need discussion somewhere. IRC or slack are both fines for me.

I don't think gcc-rust is a quick job, and I can only work on it in my part time. But I hope it can continue.

[philberty]

I have done some more code cleanup there today i have 1 more commit to push in and then i will enforce PR's only to master including on myself to keep myself honest. I also setup github workflow to check build status etc. The next part is to share my plan somehow either via blog or on this github project.

[philberty]

Posted my first hello world blog post: https://thephilbert.io/?p=11

Are people interested in a youtube style content similar as https://github.com/SerenityOS/serenity https://www.youtube.com/channel/UC3ts8coMP645hZw9JSD3pqQ

[glaubitz]

@philberty It may not be much, but I have created a Bountysource campaign to support your effort. It has not gained that much attraction yet, but it might do in the future.

[sapir]

@glaubitz I think this one also applies: https://www.bountysource.com/issues/86138921-rfe-add-a-frontend-for-the-rust-programming-language

[glaubitz]

That's the one I created :-).