Hi everyone, As the cut-off for merging is coming up in November, quite a few of our patches have not been reviewed yet.
There are a few main issues that have been raised so far, and we are fixing those at the moment in preparation for version 3 of the patches. Is there anything else we can do to make reviewing the rest of the patches easier? Thanks --Phil On Mon, 11 Jul 2022 at 16:02, David Edelsohn <dje....@gmail.com> wrote: > > On Mon, Jun 27, 2022 at 10:52 AM Philip Herron > <philip.her...@embecosm.com> wrote: > > > > Hi everyone, > > > > Since November 2020, I've worked full-time on the Rust front-end for > > GCC, thanks to Open Source Security, Inc and Embecosm. As a result, I > > am writing to this mailing list to seek feedback from the collective > > experience here early to plan a path for upstreaming the front-end > > into GCC. > > > > 1. What is the actual process of merging a prominent feature like this > > upstream > > - How do we review this? > > - Do we create a "mega-commit" patch > > - How long should we expect this review process to take > > - Is there anything we can do to make this easier? > > > > 2. What sort of quality does the GCC community expect? > > - I think it is essential that we can compile valid test cases from > > a testsuite and real projects before merging. > > - It seems reasonable that our error handling may not be 100% but be > > expected to improve over time > > - Upon merging, can features like Rust be marked as experimental > > > > 3. How do GCC releases work? > > - If you miss a window can we still merge code into the front-end? > > - Can we merge without a borrow checker and backport this in the future? > > > > 4. What about the possibility of merging sooner rather than later, > > which would help the project gain interest through the increased > > visibility of it as part of the GCC family. > > - Does this still allow for development churn, or will it cause friction? > > > > 5. Does anyone have prior experience or advice they could give us? > > > > For some context, my current project plan brings us to November 2022 > > where we (unexpected events permitting) should be able to support > > valid Rust code targeting Rustc version ~1.40 and reuse libcore, > > liballoc and libstd. This date does not account for the borrow checker > > feature and the proc macro crate, which we have a plan to implement, > > but this will be a further six-month project. > > > > Regarding patch management, we currently do our development on GitHub: > > https://github.com/Rust-GCC/gccrs; this means we can integrate our > > issue tracking with the official Rust project by linking back to the > > official Rust project's RFC issues, for example. The downside is that > > when someone uses our compiler and hits an ICE, they will be directed > > to the GCC Bugzilla, which is correct but can lead to a mismatch in > > issue tracking. Nevertheless, I think it's essential to have the > > GitHub link here to integrate with the broader Rust community. I > > believe we can triage Rust issues on the Bugzilla and raise associated > > ones on Github to manage this. > > > > From my perspective as the lead on this front-end, we are currently > > under heavy development, so this means a fair amount of code churn > > still, and I don't see this changing until we can successfully compile > > the libcore crate later this year. Although I would love to see us > > merged into GCC 13, I want to make sure this project is a success for > > everyone, and this might mean pushing back to the next release window > > to make sure this is manageable to produce a quality front-end to sit > > alongside the others. > > > > I wish to thank you those in the GCC developer community, who have > > inspired me and helped me navigate my journey to this point in time. > > > > - Thomas Schwinge > > - Mark Wielaard > > - Tom Tromey > > - Ian Lance Taylor > > - David Edelsohn > > - David Malcolm > > - Martin Jambor > > Congratulations! The GCC Steering Committee has voted to accept the > contribution of the Rust Frontend (aka GCC Rust) to GCC. Please work > with the GCC Global Reviewers and GCC Release Managers for technical > review and technical approval of the patches. We look forward to > including a preliminary, beta version of GCC Rust in GCC 13 as a > non-default language. > > Thanks, David -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
