Try   HackMD

GCC Rust Meeting 2023-02-13

Agenda

  • Project Reports
    • Monthly report
    • What are we working on
    • Reviewing and Management
    • GCC Upstream Merge
    • GCC Rust github page
  • Questions

Project Reports

Monthly report: upcoming

What are we working on

Questions

Feel free to add questions!

Reviewing and Management

We're now getting a lot more pull-requests to review and it'd be nice to add automation there as well, and figure out a workflow for reviewing.

  1. How do we separate the codebase for reviewing?
    • CodeOwners.txt like llvm?
    • GitHub CODEOWNERS feature can auto-assign reviewers
  2. How much do we separate it?
    • AST
      • lexer
      • parser
    • Expansion
      • cfg
      • macros
    • Name Resolver
      • early
      • late
    • HIR
      • HIR lowering
    • Type resolution
      • lang-items
      • Trait resolving
      • bounds-checking
      • tyty type's
    • Code-generation
      • constexpr
      • Inrinsics
    • Lints
      • unsafe
      • const
      • dead-code
      • privacy
      • unused-var
      • feature-gates
    • GCC Target Hooks
    • GCC Testsuite
    • GCC Integration

Highlevel seperation

  • Philip
    • HIR-related passes
    • code-generation
  • Arthur
    • AST-related passes
    • intrinsics
    • lints

Thomas - I think "Highlevel seperation" is sufficient at this time instead of detailed per-module separation?

Nominations:

  • @tschwinge GCC Testsuite GCC Integration
    • Thomas - ACK though, my response times may be slow, and I'm happy to have another GCC/Rust maintainer preempt me (and we fix up any issues later on).
  • @dkm GCC Testsuite and GCC Integration
  • https://github.com/ibuclaw target-hooks integration

Anyone else want to volunteer

Moving forward

I think a Wiki page dedicated to this would be better served than a CodeOwners.txt for now

  • Thomas - ACK.

CI and Gcc changelogs

  • We need more CI! More bootstraps and more builds and more checks for each commit in a pull-request.
    • Thomas - Yes, generally, but also let's not overdo it. Someone has to pay for all the CI. ("Pay" as in money, but also as in environment.)
  • We need scripts for Changelogs and to add git gcc-commit-mklog without all the superfluous things.

Bors Future

Vote

Philip - I think its time to get rid of Bors and move to a merge queue.

Arthur - with rebases, but seconded :)

Marc/dkm - same. We have seen how painful the bors merge are when it comes to rebasing onto gcc master. merge queues + rebase strategy should really make things easier.

Thomas - What are the problems with bors (I don't think I've observed any?) but then, I don't care too much about which to use. (, though I generally do prefer Git merges over rebase, to not rewrite Git history but then, I don't care too much about that, either.) ;-)

Philipp K. - If history doesn't matter, there is also the squash_and_merge feature in bors that could help with that. But then again, I'd also be interested how GH merge queues will work out - I never saw a repo using them.

// anyone else?

GCC Upstream Merge

State of GCC upstream code base?

Merging upstream back to github?

Scripting?

  • Thomas if that means to auto-push things into GCC upstream master branch, I vote "no". Let's continue to manually review what we're doing. If that's scripting to auto-generate a upstreaming Git branch on top of upstream GCC master branch, then yes, that may be useful if possible to achieve without too much effort?

Now that we are enforcing gcc changelogs does this help?

GCC Rust github page

This needs updated https://rust-gcc.github.io/ its not very pretty right now and is out of date.

libproc project

github.com/orgs/rust-GCC/projects/11/

Minutes