Merge from GCC upstream into GCC/Rust

[Thomas Schwinge]

Hi "Testers"!

I'm preparing a merge from GCC upstream into GCC/Rust.  This is normally
pretty unexciting ;-) -- the exception being, as once mentioned in
:

| Aside from the GCC/Rust-specific files (not existing in GCC upstream),
| we also carry a lot of changes in 'gcc/config/' (GCC back ends
| implementations), originating in 
| "@SimplyTheOther"'s work on Rust Target Hooks.  For a few of these
| files/changes we run into merge conflicts (which I did sort out), but
| also this work may need updates corresponding to GCC upstream changes.
| As that work is (per the Git commit logs etc.) still very much work in
| progress, and I assume hasn't been tested with all the respective many
| GCC back ends, I'm not going to spend much effort on that, and just
| make sure that x86_64-pc-linux-gnu continues to work.

As for checking that the configurations that you're testing are still
fine, would you like to do (and/or fix) that before or after me pushing
the merge?


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Merge from GCC upstream into GCC/Rust

[John Paul Adrian Glaubitz]

Hi Thomas!

On 9/24/21 10:30, Thomas Schwinge wrote:
> As for checking that the configurations that you're testing are still
> fine, would you like to do (and/or fix) that before or after me pushing
> the merge?

I'm fine with testing after the merge and I'll report issues as they show
up.

Thanks for asking!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: byte/char string representation (Was: [PATCH] Fix byte char and byte string lexing code)

[Philip Herron]

Hi Mark,

This is really useful information, will this mean that the lexer token will
need to represent strings differently as well? Or is the std::string in the
lexer still ok?

The change you made above has the problem that reference types like, arrays
are forms of what rust calls covariant types since they might contain an
inference variable, so they require lookup to determine the base type. Its
likely there is a reference cycle here. Though this change will not be
correct for type checking purposes. The design of the type system is purely
about rust type checking and inferring types. So for example this change
will break the case of:

```
  let a:str = "test";
```

Since the TypePath of str can't know the size of the expected array at
compilation time. And the error message will end up with something like
"expected str got [i8, 4]"; As for the string implementation, I did some
experimentation this morning and it looks as though strings in rust are a
kind of slice that we still need to support so, for example, you can see in
this gdb session the implicit struct for the slice:

```
Temporary breakpoint 1, test::main () at test.rs:8
8   let a = "Hello World %i\n";
(gdb) n
9   let b = a as *const str;
(gdb) p a
$1 = "Hello World %i\n"
(gdb) p b
No symbol 'b' in current context
(gdb) n
10  let c = b as *const i8;
(gdb) p b
$2 = *const str {data_ptr: 0x55588000 "Hello World %i\n\000", length:
15}
(gdb) p b.data_ptr
$3 = (*mut u8) 0x55588000 "Hello World %i\n\000"
```

So to me, this is something that we will need to do in the backend with a
bunch of implicit code and types, it seems as though for this rust code:

```
unsafe {
let a:&str = "Hello World %i\n";
let b = a as *const str;
let c = b as *const i8;

printf(c, 123);
}
```

we would be creating something like:

```
struct Str {
  data_ptr: i8*;
  length: usize;
}

const char *const_string =  "hello world %i\n";
Str& a = &Slice{data_ptr: const_string, l5};
Str* b = a;
const unsigned char* c = b->data_ptr;
```

I think we should be able to fix this when we get slices working in the
compiler.

What do you think?

--Phil

On Thu, 23 Sept 2021 at 21:53, Mark Wielaard  wrote:

> On Thu, Sep 23, 2021 at 04:10:59PM +0200, Arthur Cohen wrote:
> > > Something I was thinking about outside of the scope of that patch was
> > about the utf8 how do they get represented? Is it some kind of wchar_t?
> >
> > Do you mean in C++ or in rustc? In rustc, they are represented as Unicode
> > Scalar Values which are 4 bytes wide.
> >
> > From the docs over here: [
> https://doc.rust-lang.org/std/primitive.char.html]
> >
> > So I'm assuming they could be represented as `int32_t`s which would also
> > make sense for the check
>
> Yes, for rust characters a 32bit type (I would pick uint32_t or maybe
> char32_t) makes sense, since chars in rust are (almost) equal to
> unicode code points (technically only 21 bits are used). But not
> really, it is a Unicode scalar value, which excludes high-surrogate
> and low-surrogate code points and so the only valid values are 0x0 to
> 0xD7FF and 0xE000 to 0x10.
>
> We should not use the C type wchar_t, because wchar_t is
> implementation defined and can be 16 or 32 bits.
>
> See also https://doc.rust-lang.org/reference/types/textual.html
>
> But utf8 strings are made up of u8 "utf8 chars". You need 1 to 4 utf8
> chars to encode a code point. https://en.wikipedia.org/wiki/UTF-8
> We can use c++ strings made up of (8 bit) chars for that.
>
> Our lexer should make sure we only accept valid rust characters or
> utf-8 sequences.
>
> Note that the above doesn't hold for "byte chars" (b'A') or "byte
> strings" (b"abc"). Those are really just u8 or [u8] arrays which hold
> bytes (0x0 to 0xff).
>
> We currently get the type for byte strings wrong. We pretend they are
> &str, but they really should be &[u8].
>
> I tried to fix that with the following:
>
> diff --git a/gcc/rust/typecheck/rust-hir-type-check-expr.h
> b/gcc/rust/typecheck/rust-hir-type-check-expr.h
> index fe8973a4d81..b0dd1c3ff2c 100644
> --- a/gcc/rust/typecheck/rust-hir-type-check-expr.h
> +++ b/gcc/rust/typecheck/rust-hir-type-check-expr.h
> @@ -609,15 +609,42 @@ public:
> break;
>
> case HIR::Literal::LitType::BYTE_STRING: {
> - /* We just treat this as a string, but it really is an arraytype
> of
> -u8. It isn't in UTF-8, but really just a byte array.  */
> - TyTy::BaseType *base = nullptr;
> - auto ok = context->lookup_builtin ("str", &base);
> + /* This is an arraytype of u8 reference (&[u8;size]). It isn't in
> +UTF-8, but really just a byte array. Code to construct the
> array
> +reference copied from ArrayElemsValues and ArrayType. */
> + TyTy::BaseType *u8;
> + auto ok = context->lookup_builtin ("u8", &u8);
>   rust_assert (ok);
>
> + auto crate_num = mappings->get_current_crate (

Re: Merge from GCC upstream into GCC/Rust

[Philip Herron]

Thanks for reaching out to continue helping with this Adrian, what is it
like building on some of your systems, does it take a long time?

It would be nice to track this in some kind of built matrix, would you be
interested in carving out a wiki page over on
https://github.com/Rust-GCC/gccrs/wiki? Or do you have any other ideas?

Thanks

--Phil

On Fri, 24 Sept 2021 at 10:25, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hi Thomas!
>
> On 9/24/21 10:30, Thomas Schwinge wrote:
> > As for checking that the configurations that you're testing are still
> > fine, would you like to do (and/or fix) that before or after me pushing
> > the merge?
>
> I'm fine with testing after the merge and I'll report issues as they show
> up.
>
> Thanks for asking!
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
> --
> Gcc-rust mailing list
> Gcc-rust@gcc.gnu.org
> https://gcc.gnu.org/mailman/listinfo/gcc-rust
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Merge from GCC upstream into GCC/Rust

[John Paul Adrian Glaubitz]

Hi Philipp!

On 9/24/21 13:20, Philip Herron wrote:
> Thanks for reaching out to continue helping with this Adrian, what is it
> like building on some of your systems, does it take a long time?
> 
> It would be nice to track this in some kind of built matrix, would you be
> interested in carving out a wiki page over on
> https://github.com/Rust-GCC/gccrs/wiki? Or do you have any other ideas?

Sure, if you want a matrix with build times, I can create one.

I'm currently on vacation and could work on that next week.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust