From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id E9DF938387A6 for ; Mon, 27 Jun 2022 14:52:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E9DF938387A6 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-ej1-x631.google.com with SMTP id pk21so19756176ejb.2 for ; Mon, 27 Jun 2022 07:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=axZ5ZvS5gAnton++2RHe2Ud5h9Jzw3F3RsNHgnwPtzQ=; b=JALOrgdrk0aFY/qnPIthuyX7ozRrra29jbJ7g5ed8LQK+LW1ptFQVgsJ/gZu112rPH iSVo4xsnye5x+xfL6cB2627MblPxnNST/fD52rDmOlKNSqk4nRXON9W2FN2reRxA6WiS 5JTxkgZtSNXD3irJiBuUCbyMRrPE2VBAGXJA1v+EKeDHAUErrFnr55Qnp8s0gdDJQQLZ +cIMkOy8jI1E2ZRiPV54Bf7HqwB00Lfl6RZOPA3z+rDvFhRGGoF8RN1KR9ATvVsYyYJY r3znD0Yflv+4tIsaOkXM8hPWe0kxJJY0TAireb5vHFOGEOYUwq4/bA1imbJVLYxvjMM5 Zo6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=axZ5ZvS5gAnton++2RHe2Ud5h9Jzw3F3RsNHgnwPtzQ=; b=iMKyqQ8N7K/5LsS5aCE/ed8IqTd0SESb6GfXZVZ/RhMOFjatoeWigaAMA61fZzV/ay BRgTb08FpM6GIgXGE/+ZekxtHfKTwys4kTSSojdxbBKxlyhZeimQFFw1AczmUyTLcyIV 8L/eYEaYAPuFlTrGuwisJU6T+yS3kaDPlH7gFDL/NdzkP4oyXhubf5ao4t+PFDMa7Gpe oz65i/249V2XvX7owODet7wiQZxzDzNBPFL8Zg+htmmAbqyjTkId/KH0kTiRPoVIxEv0 LDmrZIXfxIdNCe7cl8AUo6/8yqKn1yVLqzoXt2dubHkcPnzNOWUHZUToW0MS9Vo31MZo svmA== X-Gm-Message-State: AJIora+aftH8wUdffhgoPzZaoOMMCSDIm5XPNebjImZYBRinJsmxfbCM Vhkjuc0gqGp5vwvrF5mOwzNZi1zGYMqSKP0SiTPi9w== X-Google-Smtp-Source: AGRyM1tVcxG9TZBx0Fm4HaRVXYFnkNNzCC37HxA8/n6Ju1VNyWFWNZioi+3KvS129RlrgpVcBnSNtkETYNUfJ83FnnM= X-Received: by 2002:a17:907:6d05:b0:726:a670:253 with SMTP id sa5-20020a1709076d0500b00726a6700253mr5654594ejc.23.1656341523695; Mon, 27 Jun 2022 07:52:03 -0700 (PDT) MIME-Version: 1.0 From: Philip Herron Date: Mon, 27 Jun 2022 15:51:52 +0100 Message-ID: Subject: Rust front-end To: gcc Mailing List , gcc-rust@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-rust@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: gcc-rust mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2022 14:52:06 -0000 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 upst= ream - 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 =E2=80=93Phil