From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id 6DEAD3860765 for ; Fri, 26 Jan 2024 09:30:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6DEAD3860765 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6DEAD3860765 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::436 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706261411; cv=none; b=aEa+Q4vBOH2lddNAfjp/1pQl/Yzdf0j5N4mV/zSm4e3H08gxNFTWFmPs2H16h8ym/wAFVPvV67fGLC1kw4W2HngGRBz7Mh2PrwCFEysjoVXbI4Xst4wLMj3Xa5dUDpledGFFlB2HYJDd4CUFmAj3TkWcMEnnoPPaHgu57mM6EiM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706261411; c=relaxed/simple; bh=T96Fjyx5n9RcsxQABB/BuMQ+wWYn7VPK8f28kXmruOk=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=Mn+rsjPerpYrGvNOS1JrzBm+aZK6ltPA+sNUDSx2lJzSSncDKiNzc0lzKtYGKiz6DFKyBaYr7QIBJW+Uvv6zfXwPJwE60pp4rMU0Q0kPFWKD4rnVcE01UkadieNGaxjtsdVcHlhMohPBZjLsHHLl0B4LSGdHTIwGFIfWTYbES1k= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-338aca547d9so210970f8f.0 for ; Fri, 26 Jan 2024 01:30:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; t=1706261406; x=1706866206; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=5igevrC/Y5IE1hOrP0Id++SPKDQbrxIrakV3/yinvU4=; b=LwRNZWj5QlHJQ2Ngl5KdaAGFcGteSbUMDxw0/iLlVi16+FNlQLMtH1PtMUMo6aTPiG oBgRHV4bB6yoSoEAYxOlQMW+UhU2e/wO2ULZekC7H5zUCUJbUpO/6Vui6CQQfm9JqcsH RUMsyf8nbB5DOMo7qcIWy9liYu3YB2TDjjA99frXAkf98lZulNkXs75PsRo7IcPWUc9k LvS3Lu++8XZH4G/XKtr/RB8rkgC8k4R7642bof7ttNZV6wPugtahovrLWgDJrIrC3imR N+baqXExsnwFrfuDTfcfbIPFMevPxO1DjNuv2ocpcCfvpfTJHreMPl3lo0sbu6AAHsfV KF9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706261406; x=1706866206; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5igevrC/Y5IE1hOrP0Id++SPKDQbrxIrakV3/yinvU4=; b=WwDfkcj2xst0gnP/lWyFMW5sgj15wEXG+7xMVMTdbWoA7bjF4tayV6KtF2Xro8OASa Km3CQi/NozY71QSAAmWlzGjG1T0Gwi4WgjueR9YiU3ore+en/kxTlW8XvGGf/t/1bdbA iFobEs+lr+QYZgxBs5/Jrxi40yRNldqoDCUKBreaUsSoz2wvt1qgNPifKN6S1H7bK4xN QKpoeecT+sBz22w3T6lknD7lSsTcXAVtCybj390F0Fr+5x7XxAWWiOd73c4ggA+CAvkg MJRnjiE8CHm1XU5weU4o7JKnhbt7+jVboyJoLuISKLbC/4T66TfT+aQD/Z7Yn495mYM0 ZjGQ== X-Gm-Message-State: AOJu0YzG8k5HXAx8FbWOxCsnFiyC9ArGhdCGlMBm4VsnjVHfemOHBii7 PpFvRCbnrIXijuvCsjs2IFGRsejub40zIbNkL378yO2P6q2VdijkDvAx2OFvbpGE7u4PeL75sgo = X-Google-Smtp-Source: AGHT+IH+kSULicjTX82MQF/ILo8fj4ZkLaWrphdaPDQRH+v0NcUJzj3nBxpcI/w5QY2NvatTtac+Ig== X-Received: by 2002:a5d:4291:0:b0:339:4570:40c1 with SMTP id k17-20020a5d4291000000b00339457040c1mr375401wrq.102.1706261405912; Fri, 26 Jan 2024 01:30:05 -0800 (PST) Received: from ?IPV6:2a04:cec0:1900:b4ea:a904:7352:e226:659a? ([2a04:cec0:1900:b4ea:a904:7352:e226:659a]) by smtp.gmail.com with ESMTPSA id t24-20020a1709064f1800b00a349a5f9f77sm418692eju.47.2024.01.26.01.30.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Jan 2024 01:30:05 -0800 (PST) Message-ID: <677c3005-9f4f-4f3b-9eb7-4233f9f9b7e1@embecosm.com> Date: Fri, 26 Jan 2024 10:30:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Request for Comments] Using Rust libraries in the Rust frontend Content-Language: en-US To: connor horman , gcc@gcc.gnu.org References: <34fec7ea-8762-4cac-a1c8-ff54e20e31ed@embecosm.com> From: Arthur Cohen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.5 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 List-Id: Hi Connor, On 1/25/24 16:55, connor horman wrote: > Note that it may not make sense to include a source copy of rustc, as > that will itself require an (earlier) stage of rustc to build. mrustc > can offer a bootstrap for 1.54, but depending on the versions required, > you may need upwards of 10 additional rustc sources. Yes, I was a bit worried about the idea but it seems this is just me not knowing how to read so all is good. Using mrustc for this is a great idea however. Thanks! Arthur > > On Thu, 25 Jan 2024 at 10:04, Arthur Cohen > wrote: > > Hi Richard, > > On 1/23/24 08:23, Richard Biener wrote: > > On Mon, Jan 22, 2024 at 7:51 PM Arthur Cohen > > wrote: > >> > >> Hi everyone, > >> > >> In order to increase the development speed of Rust features, we are > >> seeking feedback on reusing some Rust components directly within our > >> front-end. As mentioned in other conferences, the most important > >> component we would like to integrate into the front-end is the > polonius > >> borrow-checker. Another component we've become interested in is the > >> `rustc_format_parser` library, responsible for handling parsing and > >> handling of format arguments as described in the documentation for > >> `std::fmt` [1]. > >> > >> However, since these libraries are written in Rust, GCC in > itself is not > >> yet able to compile them. They all depend on the Rust standard > library, > >> which we cannot yet compile and link properly. This obviously > raises a > >> question - how to actually compile, integrate and distribute these > >> components? > >> > >> We do have the option to rewrite them from scratch, but we feel that > >> spending time on these existing, correct, battle-tested and easily > >> integrable components instead of focusing on other aspects of the > >> language would be a mistake. Spending this time instead on Rust > features > >> that we are missing for compiling these components would, in our > >> opinion, yield more results, as it would also help in compiling > other > >> Rust programs. > >> > >> We could either distribute these components as compiled > libraries, or > >> look at integrating the official Rust compiler to our build > system as a > >> temporary measure. I am aware that this would mean restricting > the Rust > >> GCC front-end to platforms where the official Rust compiler is also > >> available, which is less than ideal. > > > > But that's only for the host part - you can still cross compile > to another > > target and possibly, once the GCC frontend can compile these > libraries > > itself, also use them to bootstrap a hosted version on that target - > > speaking of .. > > > >> However, this would only be > >> temporary - as soon as the Rust front-end is able to compile these > >> components, we would simply reuse them and compile them with > gccrs as > >> part of our bootstrapping process. > > > > .. gccrs would then need to be able to build itself without those > modules, > > at least during stage1 so that the stage1 compiler can then be > used to > > build them.  Or you go like m2 and build a "mini-rust" that's > just capable > > of building the modules. > > Right, that makes a lot of sense. We should definitely be able to build > the format string parser without a format string parser, as it does not > use format strings for error handling or anything. And even if it did, > it would be pretty easy to remove that and do the formatting by hand. > > Similarly, the borrow checker is not "needed" for compilation and we do > plan on building stage1 without it, while making it mandatory for > stage2/3 builds. > > > I think re-using parts already available is very sensible at this > point.  Note > > that while we might temporarily require a host rust compiler to > boostrap > > gccrs I'd rather not have the build system download something > from the > > internet - so at least the sources of those dependences need to > be in the > > GCC repository, possibly in a new toplevel directory. > > Okay, that makes a lot of sense. I was thinking of adding a basic check > for the Rust compiler to be present when compiling these components - > and error out if that isn't the case. Are you suggesting we embed a > full > copy of rustc in GCC and build it from source when compiling the Rust > frontend? Or am I misunderstanding? > > >> The documentation for `std::fmt` [1] describes all of the features > >> available in Rust format strings. It also contains a grammar for the > >> format-string parser, which we would need to re-implement on top of > >> supporting all the formatting features. As a prototype, I wrote > an FFI > >> interface to the `rustc_format_parser`  library and integrated > it to our > >> macro expansion system, which took me less than a couple hours. > In less > >> than an afternoon, we had bindings for all of the exported types and > >> functions in the library and had access to a compliant and > performant > >> Rust format string parser. But re-implementing a correct > >> `format_args!()` parser - with the same performance as the Rust > one, and > >> the same amount of features - would probably take days, if not > weeks. > >> And we are talking about one of the simplest components we aim > to reuse. > >> Something like a fully-compliant trait solver for the Rust > programming > >> language would take months if not years to implement properly > from scratch. > >> > >> I would like to stress once again that relying on distributing > compiled > >> libraries or using `rustc` in our build system would be > temporary, and > >> that these measures would be removed as soon as gccrs is able to > compile > >> these components from source. > >> > >> I am looking for comments on this decision as well as the best > practices > >> we could adopt. Have there been any similar decisions for other > >> self-hosted front-ends? Any previous email threads/commits that you > >> could point me to would be greatly appreciated. > > > > Not in this very same way but the D frontend is a shim around the > official > > DMD frontend and the Go frontend imports the golang standard library > > (but the frontend itself is written in C++ and doesn't use any > part of it). > > > > The C++ frontend uses part of the C++ standard library (but it can of > > course build that itself - but it requires a host C++ compiler > with library). > > Thanks for the pointers. I was wondering if this is something that the > Ada frontend had faced at the beginning, but I've been told it does not > have a lot of dependencies anyway so this might not be helpful. > > > > > Richard. > > > >> Thanks, > >> > >> Arthur > >> > >> [1]: https://doc.rust-lang.org/std/fmt/ > > > Thanks a lot for taking the time, I really appreciate it. > > Best, > > Arthur >