Re: Rust front-end

[Philip Herron <philip.herron@embecosm.com>]

Hi David

We made a table to try and track this a bit better:

| Patch                                                           |
Reviewed | Accepted |
|-----------------------------------------------------------------+----------+----------|
| 0001-Use-DW_ATE_UTF-for-the-Rust-char-type.patch                | x
      | x        |
| 0002-gccrs-Add-nessecary-hooks-for-a-Rust-front-end-tests.patch | x
      | x        |
| 0003-gccrs-Add-Debug-info-testsuite.patch                       |
      |          |
| 0004-gccrs-Add-link-cases-testsuite.patch                       |
      |          |
| 0005-gccrs-Add-general-compilation-test-cases.patch             |
      |          |
| 0006-gccrs-Add-execution-test-cases.patch                       |
      |          |
| 0007-gccrs-Add-gcc-check-target-check-rust.patch                | x
      |          |
| 0008-gccrs-Add-the-Rust-front-end-AST-data-structures.patch     |
      |          |
| 0009-gccrs-Add-Lexer-for-Rust-front-end.patch                   | x
      |          |
| 0010-gccrs-Add-Parser-for-Rust-front-end.patch                  |
      |          |
| 0011-gccrs-Add-expansion-pass-for-the-Rust-front-end.patch      |
      |          |
| 0012-gccrs-Add-name-resolution-pass-to-the-Rust-front-end.patch |
      |          |
| 0013-gccrs-Add-second-intermedite-representation-called-H.patch |
      |          |
| 0014-gccrs-Add-AST-to-HIR-lowering-pass.patch                   |
      |          |
| 0015-gccrs-Add-wrapper-for-make_unique.patch                    |
      |          |
| 0016-gccrs-Add-port-of-FNV-hash-used-during-legacy-symbol.patch |
      |          |
| 0017-gccrs-Add-Rust-ABI-enum-helpers.patch                      |
      |          |
| 0018-gccrs-Add-Base62-implementation.patch                      |
      |          |
| 0019-gccrs-Add-implementation-of-Optional.patch                 |
      |          |
| 0020-gccrs-Add-attributes-checker.patch                         |
      |          |
| 0021-gccrs-Add-helpers-mappings-canonical-path-and-lang-i.patch |
      |          |
| 0022-gccrs-Add-type-resolution-and-trait-solving-pass.patch     |
      |          |
| 0023-gccrs-Add-unsafe-checks-for-Rust.patch                     |
      |          |
| 0024-gccrs-Add-const-checker.patch                              |
      |          |
| 0025-gccrs-Add-privacy-checks.patch                             |
      |          |
| 0026-gccrs-Add-dead-code-scan-on-HIR.patch                      |
      |          |
| 0027-gccrs-Add-unused-variable-scan.patch                       |
      |          |
| 0028-gccrs-Add-metadata-ouptput-pass.patch                      |
      |          |
| 0029-gccrs-HIR-to-GCC-GENERIC-lowering.patch                    |
      |          |
| 0030-gccrs-These-are-wrappers-ported-from-reusing-gccgo.patch   |
      |          |
| 0031-gccrs-Add-GCC-Rust-front-end-Make-lang.in.patch            | x
      |          |
| 0032-gccrs-Add-config-lang.in.patch                             | x
      | x        |
| 0033-gccrs-add-lang-spec.h.patch                                |
      |          |
| 0034-gccrs-add-lang.opt.patch                                   | x
      |          |
| 0035-gccrs-add-compiler-driver.patch                            |
      |          |
| 0036-gccrs-compiler-proper-interface-kicks-off-the-pipeli.patch |
      |          |
| 0037-gccrs-Add-README-CONTRIBUTING-and-compiler-logo.patch      |
      |          |

I think the formatting from org-mode didn't come through 100%, but it
looks readable enough. The patches which are reviewed but not accepted
have issues which we have fixed locally in preparation for sending
version 3 of the patches. I also found using this link made it much
easier to see which patches have had reviews and which have not:

https://inbox.sourceware.org/gcc-patches/20220824115956.737931-9-philip.herron@embecosm.com/T/#rbff0bb3df2780fecd9ee3d2baa864d9140d24b54

You can easily see the thread of patches and those which have
responses and which have not.

Thanks

--Phil

On Tue, 4 Oct 2022 at 13:43, David Malcolm <dmalcolm@redhat.com> wrote:
>
> On Tue, 2022-10-04 at 13:29 +0100, Philip Herron wrote:
> > 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?
>
> Do you have a list of which patches need reviewing?
> e.g. perhaps a page showing:
> - which patches are waiting for a reviewer, as opposed to
> - which patches are already approved
> - which patches have issues identified in review
>   - ...where no-one is yet working on addressing them
>   - ...where someone is working on addressing them
> etc
>
> to make it clearer what the next action is for each patch, and who is
> meant to be taking it.
>
> (within Red Hat, we used to call this "who has the ball?")
>
> Hope this is constructive
> Dave
>
> >
> > Thanks
> >
> > --Phil
> >
> > On Mon, 11 Jul 2022 at 16:02, David Edelsohn <dje.gcc@gmail.com>
> > wrote:
> > >
> > > On Mon, Jun 27, 2022 at 10:52 AM Philip Herron
> > > <philip.herron@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
> >
>