# GCC Rust Meeting 2022-06-10

- Date/Time: 10th June 2022 at: 09h00 UTC
- Mailing list: https://gcc.gnu.org/mailman/listinfo/gcc-rust
- Zulip: https://gcc-rust.zulipchat.com/
- IRC: irc.oftc.net #gccrust
- Video Link: https://meet.jit.si/gccrs-community-call

## Agenda

- Project Reports
- What are we working on
- Upstreaming
- Questions

## Project Reports

Monthly report: https://github.com/Rust-GCC/Reporting/blob/main/2022-05-monthly-report.org

### What are we working on

#### philbert
- Path resolution
- crate::foo::bar::...
- super::super::super...

#### Arthur
- Testing project
- Planning for next milestone
- Online dashboard!

### Upstreaming

- GCC Git Branch: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master
- GCC Bugzilla: https://gcc.gnu.org/bugzilla/editcomponents.cgi?action=edit&product=gcc&component=rust

#### Draft mail to the GCC mailing list

Hi everyone,

Since November 2020, I've been working 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.

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. The front-end will likely still be needing improvements to error handling but will improve over time. I have received interest from people seeking to see this front-end upstreamed sooner than later, so the goal here is to hear feedback on how other features managed the "get it out" vs "is it ready?".

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.

The other major issue is managing patches; where we currently use GitHub and PR's, we support people sending patches via mail to our mailing list. Given my preference for GitHub and its integration with the Rust ecosystem, it seems natural for it to be the front-end's main development area. We then need a process whereby we upstream patches when we know they are ready in batches. I would see the upstream GCC as the good-to-release branch of the front-end, whereas GitHub is where we have room to spread our wings. For example, we don't enforce the changelog for every commit message at the moment.

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 much until we can successfully compile the libcore crate. An option enabling merging sooner rather than later is to backport features if they are missed in this window for the next GCC release and ensure this front-end is marked as experimental or preview. Alternatively, we could produce preview releases on GitHub when we support libcore and libstd and let interested parties test this prior to any merge upstream to get user feedback.

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.

Thank you to the GCC developer community, who have inspired me and helped me navigate my journey to this point in time.
> [](Thank specific GCC contributors here, as OSS/Embecosm were already thanked above)

Thanks

--Phil

## Questions

### Merge windows in GCC

Feature freeze in November for GCC 13. Current project plan runs to November 2022, all going well we should be able to compile libcore 1.49.0/liballoc/libstd.

What will be missing:

- libproc (in theory libproc compiles ok but we need the RPC interface back to the compiler)
- borrow checker (~6 month project to get polonius support)

Possible solution was to backport these features.
Given that GCC/Rust is a new front end, and not classified "release-critical", we may continue doing that until the actual GCC release branch is created (~ April).

Issues:
- We still have code churn
- This seems very tight for us

Solutions:
- In November have experimental packages built that people can try out as a "preview release"
- Always maintain our GCC branch to show our intention is there

### What sort of quality does GCC community expect

- Testing
- Valid rust programs from rustc testsuite
- Do all of our diagnostics have to be the same as Rustc?
- Can we incrementally improve our diagnostics over time
- Over time start using Rustc's error codes

I think if we can compile all of the "valid" rust programs that is definetly huge milestone of gccrs.

### Can a feature like the front-end be marked (experimental)

- So that people don't expect all of the features?
- not enabled by default
- -fyes-I-really-want-to-use-this-frontend-I-know-what-could-go-wrong

### Keeping up to date with GCC master

- What effort is there in keeping up with master
- now and again there is some issues
- We don't have a good feeling for how much effort to keep up with master

### How do we manage patches

- Keeping GH as our main repo
- Keeps community integration with Rustc
- Link issues against Rustc RFC processes
- Demonstrate our willingness to work with Rustc
- Github automation on PR's
- We haven't had any regression's since Bors

- Problems
- gcc-patches confusion
- any ICE's/bugs users will be pointed to bugzilla

- Solutions:
- Bots to raise patches from GH back to gcc-patches
- Ask that patches for Rust front-end to be posted to our mailing list
- Bot's can raise the PR's to GH from patches posted to our mailing list
- Bugzilla might be best to triage these manually

### GCC automation

https://sourceware.org/pipermail/overseers/2022q2/018453.html

- automation to merge up to our GCC git branch

### Quick demo of web app

Also mentioned: https://builder.sourceware.org/testruns/