From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) by sourceware.org (Postfix) with ESMTPS id BEA4D385841F for ; Wed, 5 Oct 2022 09:36:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BEA4D385841F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-vs1-xe36.google.com with SMTP id u189so17230717vsb.4 for ; Wed, 05 Oct 2022 02:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=QDOh9NvM90zvH8h9x1yz8z1v4ErnPqH4tcMRBdwNTqk=; b=VQ+5zRED8DKX8meBubsbaP/96iaTTrOv+tX1Zy5K9lyzIFeZ3Abo6ZgBiDFI/QoQ01 F4EYuNXQrLCxK2Xt7jaqkfxg68r6MeuZ94yb3OLMPUAS9WQdAd5HgAJiO4u0PojQ65ng vAc+TnMdhRo7Qox9vWB57GTh3q6ylMipZqsPWNNipTaoqrPK414zWeqq0vmMdTSG2zb4 IZxhr4uprZmErcEhvjMux+bVLG2LQZoYbbecMXnVWmKUZiRKJxps9fADXd0nzMX2xPvP pcoB5PtkP7ifQPz+MrUzFkW9UMQm8AZPNEXqdFYisOUQj3EIofPC/utiFEIWRuU8qTm3 rkYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=QDOh9NvM90zvH8h9x1yz8z1v4ErnPqH4tcMRBdwNTqk=; b=IdfKmC0ok04I8KAjAwDshgjFNkCRcgOSwedPzqdfDYbPakSGjKMyHgL+eRkV820OLx +GrZrGJSJp2TCi5cXB2Ui7k6bRDlKbmg3S9VWkhMkA8Zx7mfNUdNK1pcDWUOX+OWTZ+a mLnVEaB/mNYqZ6wB3AaGVC+x+aqqVsw/WGvOu1fg/SdJLVFS1UyQStpIaTcY/+IvyXMZ y4hVTSAOSWrnt/8jprYynartt8FGuc3I0aUMlUdSf1tdExVRyDXZWwk7L/abFJ9Tlo3r XYJPv5SNCOpwFgZOfpivGyWbL2UekgSWnrwQzgqT98nyVCaUXwFMAx++Cv7EcIqAP/+q Z/ww== X-Gm-Message-State: ACrzQf3z5u939yb+GXqyf1yvfhTGzFSccZVpQc/VDIhJBzzhDzko32Un DEfikUegljtM7PEVPWnqwMRK2lu8NqY8yy0YeowHmg== X-Google-Smtp-Source: AMsMyM5bQ5833utvxAID/JhxRL7v/Lo1gRSNHEVb9O69zUbFIVWLgUhHr6cMY6kyj9LzeG0l7PVFRe3GVF3mPuDHREE= X-Received: by 2002:a05:6102:3118:b0:398:904a:32f7 with SMTP id e24-20020a056102311800b00398904a32f7mr12566112vsh.14.1664962581050; Wed, 05 Oct 2022 02:36:21 -0700 (PDT) MIME-Version: 1.0 References: <39865089adafe93d92571e6768bb911f9bc292a6.camel@redhat.com> In-Reply-To: <39865089adafe93d92571e6768bb911f9bc292a6.camel@redhat.com> From: Philip Herron Date: Wed, 5 Oct 2022 10:36:09 +0100 Message-ID: Subject: Re: Rust front-end To: David Malcolm Cc: gcc Mailing List , gcc-rust@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 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 > > wrote: > > > > > > On Mon, Jun 27, 2022 at 10:52 AM Philip Herron > > > 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 > > >