public inbox for gcc-rust@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Philip Herron <philip.herron@embecosm.com>
Cc: gcc-rust@gcc.gnu.org, gcc Mailing List <gcc@gcc.gnu.org>
Subject: Re: Unit Type for Rust
Date: Mon, 28 Jun 2021 12:37:45 -0500	[thread overview]
Message-ID: <20210628173745.GD668@gate.crashing.org> (raw)
In-Reply-To: <1e46162e-f873-37b7-c9cc-7855522e2d6c@embecosm.com>

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

      reply	other threads:[~2021-06-28 17:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28 13:49 Philip Herron
2021-06-28 13:51 ` Philip Herron
2021-06-28 17:37   ` Segher Boessenkool [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210628173745.GD668@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=gcc-rust@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=philip.herron@embecosm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).