From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by sourceware.org (Postfix) with ESMTPS id ACA343858C2F for ; Tue, 23 Jan 2024 07:23:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ACA343858C2F 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 ACA343858C2F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::134 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705994624; cv=none; b=cBA/WWH57AT4MOB32ir/Ob2hqBBkud5kgCB1BOh+5H+lquEp0da75qMzp4AtnxXtEgetxh2sNXIKrXM0+bxHcRhyuluD7jdXLgSQP5IaW1Ydqxn1C8N6Lo+xtsPGE9Uvkbc0gXo3KxmVQxD8/mnaSvUsljuOZ69DhqApwX+4tEw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705994624; c=relaxed/simple; bh=b2R27bDTRoOuojcyNVfANsugqKauhe2/OPFm9ytLzaw=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=X2/cfMzft533GEAr8bfNiZeeuEp3wT8Kan8p3HJlfnHnx3MfiCjwT/VqOlca4ikgF9nU5Gy71eRnU+0Dh9vxtE4MbrWZXEW8chW3IOLb7kPUnQZtrGwKN2gQQDBnAoPl2brjtco+uBNQSJ2FtSM7vLD0bRIDxN5uD2z+lVy+FC4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-50ec948ad31so4440418e87.2 for ; Mon, 22 Jan 2024 23:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705994620; x=1706599420; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jJm7siaWEcNr2hiBDd/6zAutewqkVIPVjxWtrgRuJwQ=; b=HviM6S/Yxqo8q+AR/2PasgRboVVIjv3C8Ad5/fi5iNGDxlro+xaqjxXZkPjLVfO4Cp t+RD7hUjDIuB7zlcM+K0KWnfcW+uKnxKqtnU53l9h86yi2h79R/LI+ZLZ8G74A7na6ig ryW5x8UwS2RakRGoyMMHOcWZHWVOqm2/ZbMJA0LMkprMHQC3C4cJKluLmrlpa7YqK+f3 KOYNVe23Y/6VfUfj53JzNzRzx98Gy4a65/yxCQzsi7He7wCtjMUV9uHFLT6C/biGHLH1 o0e4uPjOrpeRoBtFCGTKeRAMKVXxGAX9SG95fFGQBMvMGqPA6N1cFB5ZE3MWeLLEpAe5 ml4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705994620; x=1706599420; h=content-transfer-encoding:cc: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=jJm7siaWEcNr2hiBDd/6zAutewqkVIPVjxWtrgRuJwQ=; b=X3qJ0Br5Dh+kNrd6JnYkDHNGibWWHVj/ztbf6gVh3d0hTfdJ9SamQkoITSlxb3G7Un lLvXobWy9PzpN59rcuXXgySXgnqQSLUjJ3vEU3QxwCUmE5jeRdvjITUNjadKspcVxBZm A/euicRzRdhwmn2iipGazsmvUPz9pQRAKYSTVrQ25w4vjFxjaEKDv9VULEYvI56yM8C0 kiTXzY2IMSpgLQMBP982Uin2gqxkFqxle4Ev1Or0jdcN+N2bobfaxlW2yXGQVVKyvhFj j9uF7oBoGQzWoILC3LFn2YQg5dSWFGEalLPP64K1VBWd4FXenjG2uqGLkxxhFqeGS2K9 NmyA== X-Gm-Message-State: AOJu0YwiIARETAyBgEjf9OlGA82qIFW8eVxWikiahVFp8hdIyTnzOAR8 I6Ds8Bx8ChTUVNkf7mTY4NJf7n8fCOHQYPfs5S/dPnOBVbWat/PimeY+DOa2hxRlrlTSxzyMypj arAdjaowpb53vLAkTWHS6EdjDK8Y= X-Google-Smtp-Source: AGHT+IEaiFyHzudP1f6e915AS6u3A2uSMsY56L9RfgYS9SFE+M+2ikDDraxHByXFe2KjKMaqnPqYr6UiN5JEQjZ2+Sk= X-Received: by 2002:a05:6512:b07:b0:50e:80ff:2d0f with SMTP id w7-20020a0565120b0700b0050e80ff2d0fmr2770755lfu.98.1705994619514; Mon, 22 Jan 2024 23:23:39 -0800 (PST) MIME-Version: 1.0 References: <34fec7ea-8762-4cac-a1c8-ff54e20e31ed@embecosm.com> In-Reply-To: <34fec7ea-8762-4cac-a1c8-ff54e20e31ed@embecosm.com> From: Richard Biener Date: Tue, 23 Jan 2024 08:23:28 +0100 Message-ID: Subject: Re: [Request for Comments] Using Rust libraries in the Rust frontend To: Arthur Cohen Cc: GCC Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: 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 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. I think re-using parts already available is very sensible at this point. N= ote 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. > 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 scratc= h. > > 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= ). Richard. > Thanks, > > Arthur > > [1]: https://doc.rust-lang.org/std/fmt/