public inbox for gcc-rust@gcc.gnu.org
 help / color / mirror / Atom feed
* Rust front-end
@ 2022-06-27 14:51 Philip Herron
  2022-06-28  7:30 ` Richard Biener
  2022-07-11 15:01 ` David Edelsohn
  0 siblings, 2 replies; 10+ messages in thread
From: Philip Herron @ 2022-06-27 14:51 UTC (permalink / raw)
  To: gcc Mailing List, gcc-rust

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

Thanks

–Phil

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Rust front-end
  2022-06-27 14:51 Rust front-end Philip Herron
@ 2022-06-28  7:30 ` Richard Biener
  2022-07-08 17:31   ` Philip Herron
  2022-07-11 15:01 ` David Edelsohn
  1 sibling, 1 reply; 10+ messages in thread
From: Richard Biener @ 2022-06-28  7:30 UTC (permalink / raw)
  To: Philip Herron; +Cc: gcc Mailing List, gcc-rust

On Mon, Jun 27, 2022 at 4:52 PM 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?

Usually a new frontend is first proposed for merge and generally approved
by the steering committee (which should also sort out legal issues).

For the actual review process it's best to consult previous frontend
merges - the most recent merged frontend was the D frontend and the
modula2 frontend is in the process of being reviewed.

To be able to focus on the possibly controversical pieces separating
out changes to the generic GCC code base (such as driver or
even middle-end) should be separated out.

It would also be helpful to provide an overview of how a rust
compile + link cycle works through the pieces in GCC (see the
modula-2 case where that involved creating stub C++ code,
compiling and linking that and how this is now done much
more straight-forward).

> 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

Rust can be marked as experimental, sure.  It would be not enabled
to be built by default (and you can have a whitelist of supported targets).
The most important part would be that the build works when enabled
and that most of the existing testsuite passes so it can be used to
regression test middle-end changes.

If it is not useful at all for (basic) real-world usage then it might be not
ready yet.

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

The rust frontend will not be part of the release critical pieces of the
compiler (which includes the C and C++ frontends plus the set of
primary and secondary targets) so it is up to the maintainers to decide
what to merge and when.  Release managers will generally ignore
issues in Rust.

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

The parts where GCC and Rust overlap still need to be reviewed and
_some_ usability for users should be provided.

> 5. Does anyone have prior experience or advice they could give us?

I suppose Ian (for the Go frontend) or Iain (for the D frontend) can give
you hints.

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

If you want to target GCC 13 for experimental Rust support I suggest to
get review on the overall design (where it touches GCC) and the changes
necessary to driver and build changes.  The core frontend itself will usually
only get review on the parts that interface to the middle-end (thus
GENERIC code generation and language hooks).  Dropping in the frontend
during Stage3 (thus until the end of the year) should be possible, especially
if the driver and build changes have been reviewed already.

Richard.

> 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
>
> Thanks
>
> –Phil

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Rust front-end
  2022-06-28  7:30 ` Richard Biener
@ 2022-07-08 17:31   ` Philip Herron
  2022-07-11  7:50     ` Richard Biener
  0 siblings, 1 reply; 10+ messages in thread
From: Philip Herron @ 2022-07-08 17:31 UTC (permalink / raw)
  To: Richard Biener; +Cc: gcc Mailing List, gcc-rust

Hi Richard

Thanks for your detailed response, I took some time to figure this out
myself to give a decent response. It seems like we should keep the end
of the year as our goal to aim for but in the meantime see if we can
split patches which affect GCC over the next month or so. We have no
changes to the GCC gimple/generic IRs. Usually, when I hit something
inside the GCC middle-end, the front-end is doing something wrong,
which has helped keep me on a good path. Other than that we have
changes to:

1. Grabbing target info using the TARGET_HOOKS interfaces in gcc/config.
2. Tweaks to selftest which was already merged last year by Arthur Cohen
3. We have some minor issues with lang.opt in the latest merge from
upstream which Thomas Schwinge is working on, but I believe we can
work around this if we want
4. Our compiler driver needs some cleanup which we can do in the short
term to get it reviewed
5. We need to make some build changes to incorporate libcore being
built by gccrs which is still WIP.

As for the compile link cycle, we mostly reuse the model from the GO
front-end. In Rust the "crate" is a compilation unit, which means if
you have a project with multiple files, you point gccrs at a single
src/source.rs, the main entry point for a library (usually lib.rs).
Keywords such as "mod foo", trigger the expansion of a relative path
of foo.rs like a C++ included inside a namespace. All source files are
then included inside this single compilation unit. When the
compilation is successful, we reuse code from the Go front-end to put
custom front-end metadata into a section ".rust_export". At this
point, all source files are compiled into a single object file, which
can be compiled into an archive or shared library as required. To link
against this, it again follows similar to Go front-end, whereby the
source.rs has a declaration such as "extern crate foo"; the search
code will look for foo.o or libfoo.a (I haven't tested against shared
libraries yet) and grab the metadata out of it and parse it in the
front-end for all the necessary information such as types, public
functions and generics, etc., so we can compile any imports correctly
and emit the correct mangled symbols for linking.

Given we are still working on this I think we can try to line up all
the other GCC relating pieces for review over the summer, do we send
this as usual to gcc-patches?

Again thanks to everyone for helping me navigate this and answering my
questions.

--Phil

On Tue, 28 Jun 2022 at 08:30, Richard Biener <richard.guenther@gmail.com> wrote:
>
> On Mon, Jun 27, 2022 at 4:52 PM 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?
>
> Usually a new frontend is first proposed for merge and generally approved
> by the steering committee (which should also sort out legal issues).
>
> For the actual review process it's best to consult previous frontend
> merges - the most recent merged frontend was the D frontend and the
> modula2 frontend is in the process of being reviewed.
>
> To be able to focus on the possibly controversical pieces separating
> out changes to the generic GCC code base (such as driver or
> even middle-end) should be separated out.
>
> It would also be helpful to provide an overview of how a rust
> compile + link cycle works through the pieces in GCC (see the
> modula-2 case where that involved creating stub C++ code,
> compiling and linking that and how this is now done much
> more straight-forward).
>
> > 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
>
> Rust can be marked as experimental, sure.  It would be not enabled
> to be built by default (and you can have a whitelist of supported targets).
> The most important part would be that the build works when enabled
> and that most of the existing testsuite passes so it can be used to
> regression test middle-end changes.
>
> If it is not useful at all for (basic) real-world usage then it might be not
> ready yet.
>
> > 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?
>
> The rust frontend will not be part of the release critical pieces of the
> compiler (which includes the C and C++ frontends plus the set of
> primary and secondary targets) so it is up to the maintainers to decide
> what to merge and when.  Release managers will generally ignore
> issues in Rust.
>
> > 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?
>
> The parts where GCC and Rust overlap still need to be reviewed and
> _some_ usability for users should be provided.
>
> > 5. Does anyone have prior experience or advice they could give us?
>
> I suppose Ian (for the Go frontend) or Iain (for the D frontend) can give
> you hints.
>
> > 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.
>
> If you want to target GCC 13 for experimental Rust support I suggest to
> get review on the overall design (where it touches GCC) and the changes
> necessary to driver and build changes.  The core frontend itself will usually
> only get review on the parts that interface to the middle-end (thus
> GENERIC code generation and language hooks).  Dropping in the frontend
> during Stage3 (thus until the end of the year) should be possible, especially
> if the driver and build changes have been reviewed already.
>
> Richard.
>
> > 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
> >
> > Thanks
> >
> > –Phil

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Rust front-end
  2022-07-08 17:31   ` Philip Herron
@ 2022-07-11  7:50     ` Richard Biener
  0 siblings, 0 replies; 10+ messages in thread
From: Richard Biener @ 2022-07-11  7:50 UTC (permalink / raw)
  To: Philip Herron; +Cc: gcc Mailing List, gcc-rust

On Fri, Jul 8, 2022 at 7:32 PM Philip Herron <philip.herron@embecosm.com> wrote:
>
> Hi Richard
>
> Thanks for your detailed response, I took some time to figure this out
> myself to give a decent response. It seems like we should keep the end
> of the year as our goal to aim for but in the meantime see if we can
> split patches which affect GCC over the next month or so. We have no
> changes to the GCC gimple/generic IRs. Usually, when I hit something
> inside the GCC middle-end, the front-end is doing something wrong,
> which has helped keep me on a good path. Other than that we have
> changes to:
>
> 1. Grabbing target info using the TARGET_HOOKS interfaces in gcc/config.
> 2. Tweaks to selftest which was already merged last year by Arthur Cohen
> 3. We have some minor issues with lang.opt in the latest merge from
> upstream which Thomas Schwinge is working on, but I believe we can
> work around this if we want
> 4. Our compiler driver needs some cleanup which we can do in the short
> term to get it reviewed
> 5. We need to make some build changes to incorporate libcore being
> built by gccrs which is still WIP.
>
> As for the compile link cycle, we mostly reuse the model from the GO
> front-end. In Rust the "crate" is a compilation unit, which means if
> you have a project with multiple files, you point gccrs at a single
> src/source.rs, the main entry point for a library (usually lib.rs).
> Keywords such as "mod foo", trigger the expansion of a relative path
> of foo.rs like a C++ included inside a namespace. All source files are
> then included inside this single compilation unit. When the
> compilation is successful, we reuse code from the Go front-end to put
> custom front-end metadata into a section ".rust_export". At this
> point, all source files are compiled into a single object file, which
> can be compiled into an archive or shared library as required. To link
> against this, it again follows similar to Go front-end, whereby the
> source.rs has a declaration such as "extern crate foo"; the search
> code will look for foo.o or libfoo.a (I haven't tested against shared
> libraries yet) and grab the metadata out of it and parse it in the
> front-end for all the necessary information such as types, public
> functions and generics, etc., so we can compile any imports correctly
> and emit the correct mangled symbols for linking.
>
> Given we are still working on this I think we can try to line up all
> the other GCC relating pieces for review over the summer, do we send
> this as usual to gcc-patches?

Yes, that's the prefered way.  Having an integration branch ready for
people to play with is also useful - if you are ready you might want to
push something like that to the gcc.gnu.org repository under the devel/
namespace.

Thanks,
Richard.

> Again thanks to everyone for helping me navigate this and answering my
> questions.
>
> --Phil
>
> On Tue, 28 Jun 2022 at 08:30, Richard Biener <richard.guenther@gmail.com> wrote:
> >
> > On Mon, Jun 27, 2022 at 4:52 PM 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?
> >
> > Usually a new frontend is first proposed for merge and generally approved
> > by the steering committee (which should also sort out legal issues).
> >
> > For the actual review process it's best to consult previous frontend
> > merges - the most recent merged frontend was the D frontend and the
> > modula2 frontend is in the process of being reviewed.
> >
> > To be able to focus on the possibly controversical pieces separating
> > out changes to the generic GCC code base (such as driver or
> > even middle-end) should be separated out.
> >
> > It would also be helpful to provide an overview of how a rust
> > compile + link cycle works through the pieces in GCC (see the
> > modula-2 case where that involved creating stub C++ code,
> > compiling and linking that and how this is now done much
> > more straight-forward).
> >
> > > 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
> >
> > Rust can be marked as experimental, sure.  It would be not enabled
> > to be built by default (and you can have a whitelist of supported targets).
> > The most important part would be that the build works when enabled
> > and that most of the existing testsuite passes so it can be used to
> > regression test middle-end changes.
> >
> > If it is not useful at all for (basic) real-world usage then it might be not
> > ready yet.
> >
> > > 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?
> >
> > The rust frontend will not be part of the release critical pieces of the
> > compiler (which includes the C and C++ frontends plus the set of
> > primary and secondary targets) so it is up to the maintainers to decide
> > what to merge and when.  Release managers will generally ignore
> > issues in Rust.
> >
> > > 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?
> >
> > The parts where GCC and Rust overlap still need to be reviewed and
> > _some_ usability for users should be provided.
> >
> > > 5. Does anyone have prior experience or advice they could give us?
> >
> > I suppose Ian (for the Go frontend) or Iain (for the D frontend) can give
> > you hints.
> >
> > > 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.
> >
> > If you want to target GCC 13 for experimental Rust support I suggest to
> > get review on the overall design (where it touches GCC) and the changes
> > necessary to driver and build changes.  The core frontend itself will usually
> > only get review on the parts that interface to the middle-end (thus
> > GENERIC code generation and language hooks).  Dropping in the frontend
> > during Stage3 (thus until the end of the year) should be possible, especially
> > if the driver and build changes have been reviewed already.
> >
> > Richard.
> >
> > > 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
> > >
> > > Thanks
> > >
> > > –Phil

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Rust front-end
  2022-06-27 14:51 Rust front-end Philip Herron
  2022-06-28  7:30 ` Richard Biener
@ 2022-07-11 15:01 ` David Edelsohn
  2022-10-04 12:29   ` Philip Herron
  1 sibling, 1 reply; 10+ messages in thread
From: David Edelsohn @ 2022-07-11 15:01 UTC (permalink / raw)
  To: Philip Herron; +Cc: gcc Mailing List, gcc-rust

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Rust front-end
  2022-07-11 15:01 ` David Edelsohn
@ 2022-10-04 12:29   ` Philip Herron
  2022-10-04 12:42     ` David Malcolm
  0 siblings, 1 reply; 10+ messages in thread
From: Philip Herron @ 2022-10-04 12:29 UTC (permalink / raw)
  To: gcc Mailing List; +Cc: gcc-rust

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Rust front-end
  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:36       ` Philip Herron
  0 siblings, 2 replies; 10+ messages in thread
From: David Malcolm @ 2022-10-04 12:42 UTC (permalink / raw)
  To: Philip Herron, gcc Mailing List; +Cc: gcc-rust

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
> 


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Rust front-end
  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
  1 sibling, 1 reply; 10+ messages in thread
From: Jakub Jelinek @ 2022-10-04 13:04 UTC (permalink / raw)
  To: David Malcolm; +Cc: Philip Herron, gcc Mailing List, gcc-rust

On Tue, Oct 04, 2022 at 08:42:58AM -0400, David Malcolm via Gcc 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?")

Yeah, our policy in https://gcc.gnu.org/contribute.html states that
"Pinging patches, Getting patches applied

If you do not receive a response to a patch that you have submitted within
two weeks or so, it may be a good idea to chase it by sending a follow-up
e-mail to the same list(s).  Patches can occasionally fall through the
cracks.  Please be sure to include a brief summary of the patch and the URL
of the entry in the mailing list archive of the original submission."

If some patches have been already reviewed, others partly, others in the
works and others need review, sending a mail with those details
so that it is easy to find out what is still pending is appreciated even
more.

	Jakub


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Rust front-end
  2022-10-04 12:42     ` David Malcolm
  2022-10-04 13:04       ` Jakub Jelinek
@ 2022-10-05  9:36       ` Philip Herron
  1 sibling, 0 replies; 10+ messages in thread
From: Philip Herron @ 2022-10-05  9:36 UTC (permalink / raw)
  To: David Malcolm; +Cc: gcc Mailing List, gcc-rust

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Rust front-end
  2022-10-04 13:04       ` Jakub Jelinek
@ 2022-10-05  9:39         ` Philip Herron
  0 siblings, 0 replies; 10+ messages in thread
From: Philip Herron @ 2022-10-05  9:39 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: David Malcolm, gcc Mailing List, gcc-rust

Hi Jakub,

Thanks for this, as I mentioned in my response to David we have made a
table and use this link to try and see what's going on
https://inbox.sourceware.org/gcc-patches/20220824115956.737931-9-philip.herron@embecosm.com/T/#rbff0bb3df2780fecd9ee3d2baa864d9140d24b54

Do you think I should send a PING email to each patch which we are
waiting on review for?

Thanks

--Phil

On Tue, 4 Oct 2022 at 14:04, Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Tue, Oct 04, 2022 at 08:42:58AM -0400, David Malcolm via Gcc 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?")
>
> Yeah, our policy in https://gcc.gnu.org/contribute.html states that
> "Pinging patches, Getting patches applied
>
> If you do not receive a response to a patch that you have submitted within
> two weeks or so, it may be a good idea to chase it by sending a follow-up
> e-mail to the same list(s).  Patches can occasionally fall through the
> cracks.  Please be sure to include a brief summary of the patch and the URL
> of the entry in the mailing list archive of the original submission."
>
> If some patches have been already reviewed, others partly, others in the
> works and others need review, sending a mail with those details
> so that it is easy to find out what is still pending is appreciated even
> more.
>
>         Jakub
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2022-10-05  9:39 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-27 14:51 Rust front-end 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
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

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