From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id 31A743858408 for ; Mon, 22 Jan 2024 17:30:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 31A743858408 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 31A743858408 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::333 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705944649; cv=none; b=RmQh+vFrgTn4Q1EYJsi5Q6z2z3k/Uk8Klb7TmysS6F6K50oQpS3NZLbeO1aJRHb5QMI/eWxlbh9VE78DZEX8oyQzie9nA3lLnnMZfY9Si8j5412NDsKNCrpvk2ULwPv27cDCBAGgAYDoRa1ar9AR2bQD31F4n50eBYN8B1Sr+KM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705944649; c=relaxed/simple; bh=1wxJHanDyPISl5ScoOXyf7NcPg8SR7Y6qBbmos1MaYM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=wI0lTc7RMJuCoSCxe3dRe6ifNCC6L9hoOL8JhNbiMYAFHgXjnQBtN1ZM4OiBtVUz68FyZjWCr4q9I9xrRqpZguFIeIC1bjTg3yHHBgtyzqmn7rhST7Uy2awqCpaSSCoM2pz2Nvi011i0PV5Bh9YPTJk0bt28y3irS75YBJJ9Je0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-40e8801221cso34270035e9.1 for ; Mon, 22 Jan 2024 09:30:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; t=1705944644; x=1706549444; darn=gcc.gnu.org; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=/EvqzcYa0yUYB8ooX6XaZg5JVPNplCSWYNGiRk7h2Kw=; b=ALZuaG7I6niFgnNAQxAOsDytmWdissd3bVc3bPrkPxNvoI+XURk8wfihttTfEiir6I VmjT2/fROeKdUc1fDfA6t6+5kaAopZsp39dF0GF6J+NmXgWIuSL/34j+Huk71P8mWx+I fAyoHvfHzT/mu32T2DQZNRLzGPRE60AbQf4DwDPAQZQ75KbJhMcIEDP9RL6pmKb6ytNu x5r5eg7oeWdarNqncB/taG8B527du7UrtEZjmz60TEX5uhX5uJDt9qElbKnEOaVQMM2y fQb70oIwnjXCI47ihECgo1I30GWEB02CpFgVtZlHNPzVR+jjZM49yF3AVF8/nSB9utLl 6cZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705944644; x=1706549444; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=/EvqzcYa0yUYB8ooX6XaZg5JVPNplCSWYNGiRk7h2Kw=; b=osMUN5TfUdWYYQfdOMA1q25DpGZYdGvlD+tKjf7+1/IhwlNWode1T7oIvmpz4nGae2 Ly4npsEJjd42n0lErTJWn/CGN4hnQnYWuHT0bDl8smezBCPbVRbm9uKIe1sXq8GxlGBA ZS/AEv45p/UmLcazNSyr5B77su3f9sj5QRcspvLIl9XOyAK2Ezz9yn6P1xax8+K/4I5d uqXDW/5wUP7vAu1eKo3t95GnhFx8qrWXOuFdF82uzIhLjaYqY0g6HtcXt+XiO3QJvPhF 6HInPzKVOfCbhFbzCKUuWR5530jk1pNpF1AxlTdWlP3W3miDxyOCHgtUKML3PNi/1M9Q O5PA== X-Gm-Message-State: AOJu0YyuA6Cur0tcJBXqKSXr603agHeI1xEUD0em9mDRhcGP965Fd9GD Tjy8bIifID4NEbb/aa7ZBjmR/b9yGep0kjPetn8AvY4bRqMULCEDxcsUk5vG92hGj4vxIefjlwU ktA== X-Google-Smtp-Source: AGHT+IFU/mhWf1TsHBy3csuofGPWcgGaG7qG4aragDO4pwivv3FpZ628bvpA/7OIYqnXANvlKw/IuA== X-Received: by 2002:a05:600c:548c:b0:40e:8e99:57f0 with SMTP id iv12-20020a05600c548c00b0040e8e9957f0mr2826814wmb.45.1705944644513; Mon, 22 Jan 2024 09:30:44 -0800 (PST) Received: from ?IPV6:2a04:cec2:20:e09e:f09a:dd54:872:4108? ([2a04:cec2:20:e09e:f09a:dd54:872:4108]) by smtp.gmail.com with ESMTPSA id v21-20020a05600c445500b0040e3bdff98asm43296901wmn.23.2024.01.22.09.30.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jan 2024 09:30:44 -0800 (PST) Message-ID: <34fec7ea-8762-4cac-a1c8-ff54e20e31ed@embecosm.com> Date: Mon, 22 Jan 2024 18:30:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: GCC Mailing List From: Arthur Cohen Subject: [Request for Comments] Using Rust libraries in the Rust frontend Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 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. 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. 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. Thanks, Arthur [1]: https://doc.rust-lang.org/std/fmt/