public inbox for gcc-rust@gcc.gnu.org
 help / color / mirror / Atom feed
From: Philip Herron <philip.herron@embecosm.com>
To: gcc Mailing List <gcc@gcc.gnu.org>
Cc: gcc-rust@gcc.gnu.org
Subject: Re: Rust front-end
Date: Tue, 4 Oct 2022 13:29:49 +0100	[thread overview]
Message-ID: <CAB2u+n05iJ3cHFQFMxQz2jZGWQVqyLgHJKxU4tBT0B5e9ZpCWg@mail.gmail.com> (raw)
In-Reply-To: <CAGWvnym7--36T6L6XhhVhQmafR-w3g1NE1Zh9qTbjcC325Us1Q@mail.gmail.com>

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.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

  reply	other threads:[~2022-10-04 12:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-27 14:51 Philip Herron
2022-06-28  7:30 ` Richard Biener
2022-07-08 17:31   ` Philip Herron
2022-07-11  7:50     ` Richard Biener
2022-07-11 15:01 ` David Edelsohn
2022-10-04 12:29   ` Philip Herron [this message]
2022-10-04 12:42     ` David Malcolm
2022-10-04 13:04       ` Jakub Jelinek
2022-10-05  9:39         ` Philip Herron
2022-10-05  9:36       ` Philip Herron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAB2u+n05iJ3cHFQFMxQz2jZGWQVqyLgHJKxU4tBT0B5e9ZpCWg@mail.gmail.com \
    --to=philip.herron@embecosm.com \
    --cc=gcc-rust@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).