From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id AD3033861879 for ; Thu, 25 Jan 2024 15:55:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AD3033861879 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AD3033861879 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::629 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706198146; cv=none; b=lsFKNu+E1NoQVGjSdBuL99kGSdZ7n/QttP6sIRLELhSw7URgCFJRzXLmQy4ycspOlG12IViUQNdpqpfzVqJcjvtsD08H8+p0rvSx1KuVtTueEd6gi7Byd5cp5q2G+bjvrbUdc9DlvxDwMkBYF6dDnK4gN++9B3xjGZwyCrOTmtc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706198146; c=relaxed/simple; bh=xTMV2RVvvpfH2ezHZrnvsVX35hZwnx99rM1ekwCaRXU=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=MHjFGQA3QU3CJUHn/B/srAZtqCIltE7vpn72OS67dP+q54dxjNINIPwetQpEBxNmMH8RgbawoAohBbo9BYzfhOzJF730DBhqk55MUCohfHpuHsYKfO3rHsMdWyPsFBltgOdOM7v7gePGkJvFQql+kXpA8JvgaCZokAZAlH1M+2U= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a33c91ca179so27550666b.3 for ; Thu, 25 Jan 2024 07:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706198142; x=1706802942; darn=gcc.gnu.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=8K+ouBXL1CC5MfFJv7k93tOVP3n7ik3s5w04piUWeSk=; b=OiQutE8zkt9WgK/Xc8p7nSZuuuW3BlG8/27xVPHYrcIuBnHTp8FyiPuwEONHkp97og Cbx5xq6tD7et2W0aqZHHU970pkee/vJn8AtiCVMepcaW69T+XLFDJDNgtjqruorpng4V vds1UE9ArOIzLcpfyiMAWaWuIdNwtKTXubgZcOXrJDhGiNb9u9lez2LrmEMnRrQ1+zaF Iyrg2Eske1na6IPLrTFJTjEx0Dl9jSExazW7OODla/lYUhcWZfi5tHVx4h1s5BzFqGpr ohZyyanmtWTJ59TCSGFg3qfZWV92AmTvaV/jJ7KF2YP7CHtoMKkTSmn3t/BLLtxMyf+p TdXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706198142; x=1706802942; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8K+ouBXL1CC5MfFJv7k93tOVP3n7ik3s5w04piUWeSk=; b=mJxVM8iR+1WuQGxWdQDyCBISiR8mOMhQ7T/JDtvDwkijxm6gY3pC6GRsS3QOuygfTn QwnS3+0AY8mL+Cp6pN/FeVgAACTqidhNatDfBxIvh+7Qa7EscLbTjpuubgusc2awkoky O0TNc5DtL9iZTlqiFrzuGA/Mc59ot61dN51qJmoi4zPEUG1c72JS3LsXTj4uzcWy3QOx ipZJppMi+kulA5xhHX/75J2HVGsLW0RU9o5Z9SRJ6RxRwp/M4zNBMXxKGJs4OBYzj9Eu uKld2ENv3Uum6bAoBR9Fkcxnm3G4Ixn1VGJgvt6y/LUUpintbLVvNrIJ9sAM6qruhXuD eQTA== X-Gm-Message-State: AOJu0Ywf4nJHsWzP5x9sSz5mOVZOYJFSiUkacdxSB12WfCMGjQiCyXpv ohbSH2bRUxtTRV+kUZ9HTOh+Eg6suQKrCZ/awR8qBrd+Addr1Y4Tq/aekWMK+efMUz+582rsHe4 8qVe83QpKitd1bTyHUQIry6l4sSn1b0zN X-Google-Smtp-Source: AGHT+IHU7uHx7HaSGlkpgFIE3uwTeeUQTK9u+83UF7kBfkSgiLc5Pt2v7x4gs9XJj/9fTRDq+lnuanrkek1d4jvYIF0= X-Received: by 2002:a17:907:8b90:b0:a26:ee83:8841 with SMTP id tb16-20020a1709078b9000b00a26ee838841mr718277ejc.33.1706198142033; Thu, 25 Jan 2024 07:55:42 -0800 (PST) MIME-Version: 1.0 References: <34fec7ea-8762-4cac-a1c8-ff54e20e31ed@embecosm.com> In-Reply-To: From: connor horman Date: Thu, 25 Jan 2024 10:55:29 -0500 Message-ID: Subject: Re: [Request for Comments] Using Rust libraries in the Rust frontend To: Arthur Cohen , gcc@gcc.gnu.org Content-Type: multipart/alternative; boundary="0000000000002c23ac060fc736a0" X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,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: --0000000000002c23ac060fc736a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. 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=E2=80=AFPM 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 n= ot > >> 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 featur= es > >> 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 t= he > > 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 o= ur > >> 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, a= nd > >> 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 reus= e. > >> 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 compi= le > >> these components from source. > >> > >> I am looking for comments on this decision as well as the best practic= es > >> 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 > --0000000000002c23ac060fc736a0--