From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id DC7B839C2028; Mon, 28 Jun 2021 17:39:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DC7B839C2028 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 15SHbjuv022955; Mon, 28 Jun 2021 12:37:45 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 15SHbjg4022954; Mon, 28 Jun 2021 12:37:45 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 28 Jun 2021 12:37:45 -0500 From: Segher Boessenkool To: Philip Herron Cc: gcc-rust@gcc.gnu.org, gcc Mailing List Subject: Re: Unit Type for Rust Message-ID: <20210628173745.GD668@gate.crashing.org> References: <1e46162e-f873-37b7-c9cc-7855522e2d6c@embecosm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1e46162e-f873-37b7-c9cc-7855522e2d6c@embecosm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-rust@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: gcc-rust mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 17:39:49 -0000 On Mon, Jun 28, 2021 at 02:51:22PM +0100, Philip Herron wrote: > On 28/06/2021 14:49, Philip Herron wrote: > > In Rust the language has the notion of the unit type '()', so for example: > > > >  fn foo ->i32 { ... } > >  fn bar() { ... } > > > > Foo has the return type i32, and bar has no return type, which means it > > is unit-type so that it can be a value assignable just like any other > > function call. You can also declare unit-structs or unit as a type on > > variables: > > > >  struct foobar; // empty unit struct > >  let a:() = (); // unit type So you probably should have the unit type only in the language code, and use an actual type for anything later? Or can the actual type stay unknown as well? That is new territory for GCC. > > I thought I could use GCC's void_type_node to represent the unit type > > and void_node for the value when assigning or using it, but this causes > > the ICE: "void" already has a meaning, and it is not this. > > Then Tom Tromey suggested I try a zero precision integer so I called: > > make_unsigned_type (0) for the type and then use integer_zero_node for > > the value, and this solves the problem; however, if I use this zero > > precision integer type for the return type on functions and turn > > optimizations on I get the ICE: > > > >    ``` > >    test.rs: In function ‘main’: > >    test.rs:16:1: internal compiler error: in min_value, at wide-int.cc:346 So you'll need to update the max/min code to know about this. Or, don't expose unit type in generic code at all? Can the language code not always lower it to an actual type instead of the placeholder it is? There will be many more places things will break after vrp1. Including many RTL passes. Segher