From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp001-out.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by sourceware.org (Postfix) with ESMTPS id CE5CF3858D38 for ; Thu, 25 Jan 2024 16:26:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CE5CF3858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sandoe.co.uk ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CE5CF3858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=85.119.248.222 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706199987; cv=none; b=tEgtfnarB73oLwq4QmlE88I+NsaNH13vG0Qw7pQR2sy+XB+I/rF6CiWrOWo0O9xma7PAYCo+b82dTPgtbX/MGrSkPrOu80+Kldt5lHBRpiv1CytZgDdQO145xIBHQd/fQMzA28kmHpfMOlNIBaZj3YDv/svp61XpRVe0UF6MD84= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706199987; c=relaxed/simple; bh=IuasEfbe9afvBHMmWH2oeu6w7zl6TGOTbwfGLKNB5QY=; h=Mime-Version:Subject:From:Date:Message-Id:To; b=d+s9tZMfEoTI5WIYNyfvOdlJ+z0a/P3rZ6R8S2gJGNP0ic4hzTC8rXz6rxvWUEu+QBY81ObhPGuPCEkgWhZgnDxvcMn8VMUz/7Eau7c4hGT2MnptWX3ah6wVqoowTC6UtcNpg4ZY//gO/vkL5fHtxuhGSfH71d5z7k76vQrJfv8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: (qmail 46082 invoked from network); 25 Jan 2024 16:26:23 -0000 X-APM-Out-ID: 17061999834608 X-APM-Authkey: 257869/1(257869/1) 6 Received: from unknown (HELO smtpclient.apple) (81.138.1.83) by smtp001.apm-internet.net with SMTP; 25 Jan 2024 16:26:23 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Subject: Re: [Request for Comments] Using Rust libraries in the Rust frontend From: Iain Sandoe In-Reply-To: Date: Thu, 25 Jan 2024 16:26:23 +0000 Cc: GCC Development Content-Transfer-Encoding: quoted-printable Message-Id: <5B813D2B-1CBF-4895-AE24-CE5B99DCA588@sandoe.co.uk> References: <34fec7ea-8762-4cac-a1c8-ff54e20e31ed@embecosm.com> To: Arthur Cohen X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,KAM_COUK,KAM_DMARC_STATUS,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 Arthur, > On 25 Jan 2024, at 15:03, Arthur Cohen = wrote: > On 1/23/24 08:23, Richard Biener wrote: >> On Mon, Jan 22, 2024 at 7:51=E2=80=AFPM Arthur Cohen = wrote: >>>=20 >>> Hi everyone, >>>=20 >>> 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]. >>>=20 >>> 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? >>>=20 >>> 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. >>>=20 >>> 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. >=20 > 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. >=20 > 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. As long as you leave a route available for porting it to either new (or = old) systems which do not have rustc (or any other rust compiler = available). E.g. with Ada it is possible to port to a new platform by first building = a cross-compiler and then to use that cross-compiler to build a = =E2=80=9Cnative cross=E2=80=9D (build !=3D host =3D=3D target) to = provide an initial compiler on the target platform. Those cross compilers are not bootstrapped (it is a single stage) - but = it is reasonable to make it a condition that the $build compiler is the = same (even exact) version as the sources you are trying to port to the = new platform. thanks Iain >> 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. >=20 > 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? >=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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). >=20 > 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. >=20 >> Richard. >>> Thanks, >>>=20 >>> Arthur >>>=20 >>> [1]: https://doc.rust-lang.org/std/fmt/ >=20 > Thanks a lot for taking the time, I really appreciate it. >=20 > Best, >=20 > Arthur