public inbox for
 help / color / mirror / Atom feed
From: Philip Herron <>
To: gcc Mailing List <>,
Subject: Rust front-end
Date: Mon, 27 Jun 2022 15:51:52 +0100	[thread overview]
Message-ID: <> (raw)

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



             reply	other threads:[~2022-06-27 14:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-27 14:51 Philip Herron [this message]
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
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:

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

  git send-email \
    --in-reply-to='' \ \ \ \

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