From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id C994F3857C48 for ; Thu, 25 Jan 2024 18:19:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C994F3857C48 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 C994F3857C48 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::630 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706206802; cv=none; b=GppSvahOE6gL9ONl9eNMUGIZPfz3v9+I0j/p834bxoAsAinnh2p/SgRVVGUdiMP7C9ZZE2pCCTTUN/mLVL5iSVdndFgYRKgsTt03fLqn52pzjpK3tCBjjbzl+uXZEhu0yKuaHjcFXkbUh/0sE5WT4fRylwrWICbvLv/dAMgR924= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706206802; c=relaxed/simple; bh=bc7pod6KscJg505KNQ8VCBdkSuIoiXmfHdEYBhHqRkc=; h=DKIM-Signature:From:Mime-Version:Subject:Date:Message-Id:To; b=jk+r1AB87+e7qntLCzPTm8Ot4MzlzxqunlLZNI5/Q33U93Ik2Xwx9GyNxBpS2hWEutd9PmjbnJSmdEyhDxb3noOOh6MGg5jHBsZ67JBKnKkGWY09XABI/G+q0IYpP9rXYGfiQGD4OqMTHW68J1VAwxvpo0lyJcCx+eXlCOXIw8E= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a30359b97a8so533913366b.0 for ; Thu, 25 Jan 2024 10:19:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706206798; x=1706811598; darn=gcc.gnu.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=8jGD/nCFR4MtcL4TQSs9otbSGkCiUygNfq/sXg0704A=; b=PjVmOdDWcDhCL8Biap565gLl2hK0bLh6LGo1JYuZa8cneVeJDtiDAW+jUDPZGYleNU FPAAO99Jdm6/YTS5DZOa+JgZ2ZG+VSian1sIfe/XXU3i6BFzomlD6GvurrlRJL+IRDBS Vadk58hEi0/eXzIQDeCCbPrWmbLbHkac5UXGb7CKTH6oPw2HswkXRlSREcx3fzovCH8S AGb7YCYmK4ZV4pCdK6ZzP9nvPQBA++V1VTOzpsHEup8fM2r/lFPwKE+i/T8nK+JpkO5r eiD7r95ZUkYyJcUuAgMLkbKDvcKmyGC6Zkwy7F2+TrN38IFzT5yFuyGopDZFpNPdluzR 15FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706206798; x=1706811598; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8jGD/nCFR4MtcL4TQSs9otbSGkCiUygNfq/sXg0704A=; b=Pk6oPh2aRFAzQqU6pJa24TCOH5dBH5+aCEFF7qjubZGER06yCZg9m49UnQHExEoJpy zG6cVpRWa+hVc5AWKQiOH4Zr+G3Pm9bv3dyJ9qCNcJm4PW8bgSw89nJfjz6PQtlG6lfq +crJrpb/Ig220APGUGnbCcuSAR62g0ge4bcQqMsSGXrBizUkzVYy0JzB0v1Z/DHYawLx bVW/UkqnTupu6Vpmkl/3u9dRYpi3cRAJgfAT0DHuDR3VPQYWHQaLtVnpDDAZmmm6uGeo 2S8QfZL22BVLmTiO9031rxxhRo5t9tKoY9l1qKPwaHRR0bPDOMws3UbfH9GQUipC4eNq LiJw== X-Gm-Message-State: AOJu0YxftucLkP9t04P2EUoaT1bghJKrYzsGHf5eNBoJLyNl5uPFtWUy bayCS/SshskD9XO2erdYt1BIKmAp0UBZ1OtaPS8nDNqZWj4ccgNmQZ8dX6vm X-Google-Smtp-Source: AGHT+IFT8YoGrw67P5nafZiGN6XUXbUeaaEEr3KHtHlSj8KRMtNtUSPCYe5EQaxa2TkpDV5B3J0yPw== X-Received: by 2002:a17:906:694:b0:a31:6943:4688 with SMTP id u20-20020a170906069400b00a3169434688mr716216ejb.150.1706206797794; Thu, 25 Jan 2024 10:19:57 -0800 (PST) Received: from smtpclient.apple (dynamic-095-117-050-055.95.117.pool.telefonica.de. [95.117.50.55]) by smtp.gmail.com with ESMTPSA id tz3-20020a170907c78300b00a3472ae7782sm226318ejc.100.2024.01.25.10.19.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jan 2024 10:19:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: [Request for Comments] Using Rust libraries in the Rust frontend Date: Thu, 25 Jan 2024 19:19:46 +0100 Message-Id: <818C5FC1-9658-4A3A-AAF3-FE3D0E165E86@gmail.com> References: Cc: GCC Mailing List In-Reply-To: To: Arthur Cohen X-Mailer: iPhone Mail (21D50) X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,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: > Am 25.01.2024 um 16:03 schrieb Arthur Cohen : >=20 > =EF=BB=BFHi Richard, >=20 >> 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 anothe= r >> 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 capabl= e >> of building the modules. >=20 > Right, that makes a lot of sense. We should definitely be able to build th= e format string parser without a format string parser, as it does not use fo= rmat 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 pl= an on building stage1 without it, while making it mandatory for stage2/3 bui= lds. >=20 >> 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 fo= r the Rust compiler to be present when compiling these components - and erro= r out if that isn't the case. Are you suggesting we embed a full copy of rus= tc in GCC and build it from source when compiling the Rust frontend? Or am I= misunderstanding? No, you=E2=80=99d have the format parser and all it=E2=80=99s dependencies i= n the source tree but rely on an installed rustc to build that. Maybe that d= oesn=E2=80=99t make sense - I=E2=80=99m not too familiar with the rust compi= lation model. Richard=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 scrat= ch. >>>=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 officia= l >> 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 libra= ry). >=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 l= ot 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