From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id EFD55385840A for ; Tue, 4 Oct 2022 12:43:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EFD55385840A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664887382; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WmTldK+UWUrtD9OHvZsILAY6HJSq/R9p5vVAUO9W+3E=; b=cw1o/cLugGhOqgpyKJDtLK4UKgu99+x2TqS+E65/k52UqXpHYYoozxJ+ewldnGYiaTfAva VgHAu/ZQBAwjtbVsnYVWnEaEF90BnTvN7KUr9n5+Fn1fSLUMIDdStgN95TbQHz/VflP+2k 3P03JmL2w4pYOwDnDxzM8HofK1x50iM= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-287-sjr-N866MuyiMsS9TJfzLw-1; Tue, 04 Oct 2022 08:43:01 -0400 X-MC-Unique: sjr-N866MuyiMsS9TJfzLw-1 Received: by mail-qk1-f197.google.com with SMTP id h7-20020a05620a400700b006cebec84734so11669685qko.23 for ; Tue, 04 Oct 2022 05:43:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date; bh=WmTldK+UWUrtD9OHvZsILAY6HJSq/R9p5vVAUO9W+3E=; b=QZ8akx0lwAzvM8a9+8F5SSDnaCdDf5evb/ULtVhy9XvHeZNyJ3CO8wBXc8hXUwFbzj N8JNJBNKFEkpmdxRO6JWVmcxaTkgBINYMlf/rGooq5kpxjLoMZ8Kj2SVPOvCVSgMk/lo dWxVZcoydaej7S5CkPxMKPWUXkVyj+CljluxjJJviMPAqQn3vFRVGGr8Bm1roZoxmUBk Wx0HsWh5lizHcPRB8TiUK91hIvHU37rQt7VXUo+ZRSOyaEE/VYK66V4ua2yIf1PtEQUu sDglEF1v94qkIDuJjt0ZGS69Uc4Hrv4hH46FhZzCbi6oVOjOjU7/YNYNz7mELoBBy78l 3mMg== X-Gm-Message-State: ACrzQf12NWNsfrAB8fZEwZOzcwZwIfOlbn/0085MabU/OeE3IVIscE4a 1l8GzglDZnMXgTWCZhbI3OSsoMD5ubgga2w3EIzWDB0IHdxOEs4UXAiTu1zjFHoEXipxnPQWWq9 N/EuzFq6W5cyV4Q== X-Received: by 2002:a05:620a:d8a:b0:6bc:b32:177c with SMTP id q10-20020a05620a0d8a00b006bc0b32177cmr16508350qkl.396.1664887381111; Tue, 04 Oct 2022 05:43:01 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7yNKjIw4Diasj06SMxuKCKhjlFclMw5EtQuChCV3qTdv/jY0QRrU6e8Q11aW+q1MdNhbbalA== X-Received: by 2002:a05:620a:d8a:b0:6bc:b32:177c with SMTP id q10-20020a05620a0d8a00b006bc0b32177cmr16508336qkl.396.1664887380784; Tue, 04 Oct 2022 05:43:00 -0700 (PDT) Received: from t14s.localdomain (c-73-69-212-193.hsd1.nh.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id i10-20020ac8764a000000b0031f41ea94easm12428691qtr.28.2022.10.04.05.42.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Oct 2022 05:42:59 -0700 (PDT) Message-ID: <39865089adafe93d92571e6768bb911f9bc292a6.camel@redhat.com> Subject: Re: Rust front-end From: David Malcolm To: Philip Herron , gcc Mailing List Cc: gcc-rust@gcc.gnu.org Date: Tue, 04 Oct 2022 08:42:58 -0400 In-Reply-To: References: User-Agent: Evolution 3.44.4 (3.44.4-1.fc36) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,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: On Tue, 2022-10-04 at 13:29 +0100, Philip Herron wrote: > Hi everyone, >=20 > As the cut-off for merging is coming up in November, quite a few of > our patches have not been reviewed yet. >=20 > 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 >=20 > Thanks >=20 > --Phil >=20 > On Mon, 11 Jul 2022 at 16:02, David Edelsohn > wrote: > >=20 > > On Mon, Jun 27, 2022 at 10:52 AM Philip Herron > > wrote: > > >=20 > > > Hi everyone, > > >=20 > > > 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. > > >=20 > > > 1. What is the actual process of merging a prominent feature like > > > this upstream > > > =C2=A0 - How do we review this? > > > =C2=A0 - Do we create a "mega-commit" patch > > > =C2=A0 - How long should we expect this review process to take > > > =C2=A0 - Is there anything we can do to make this easier? > > >=20 > > > 2. What sort of quality does the GCC community expect? > > > =C2=A0 - I think it is essential that we can compile valid test cases > > > from > > > a testsuite and real projects before merging. > > > =C2=A0 - It seems reasonable that our error handling may not be 100% > > > but be > > > expected to improve over time > > > =C2=A0 - Upon merging, can features like Rust be marked as > > > experimental > > >=20 > > > 3. How do GCC releases work? > > > =C2=A0 - If you miss a window can we still merge code into the front- > > > end? > > > =C2=A0 - Can we merge without a borrow checker and backport this in > > > the future? > > >=20 > > > 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. > > > =C2=A0 - Does this still allow for development churn, or will it caus= e > > > friction? > > >=20 > > > 5. Does anyone have prior experience or advice they could give > > > us? > > >=20 > > > 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. > > >=20 > > > 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. > > >=20 > > > 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. > > >=20 > > > 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. > > >=20 > > > - Thomas Schwinge > > > - Mark Wielaard > > > - Tom Tromey > > > - Ian Lance Taylor > > > - David Edelsohn > > > - David Malcolm > > > - Martin Jambor > >=20 > > Congratulations! The GCC Steering Committee has voted to accept the > > contribution of the Rust Frontend (aka GCC Rust) to GCC.=C2=A0 Please > > work > > with the GCC Global Reviewers and GCC Release Managers for > > technical > > review and technical approval of the patches.=C2=A0 We look forward to > > including a preliminary, beta version of GCC Rust in GCC 13 as a > > non-default language. > >=20 > > Thanks, David >=20