Re: GCC Rust monthly call

[Philip Herron]

Hi everyone,

Just a reminder that tomorrow is the community call: at 10am utc+1. The
agenda so far is detailed within: https://hackmd.io/rBFlwl_9TkWLox-X6jyxDg

The call will be hosted on Jitsi, here is the link we will use:
https://meet.jit.si/259057065581073

Thanks

--Phil

On Mon, 31 May 2021 at 12:48, Philip Herron 
wrote:

> Hello,
>
> On the first Friday of every month, GCC Rust has a community call. The
> next one will be on the 4th of June 2021, at 10am utc+1 (I am based in
> Northern Ireland). We use our zulip server
> (https://gcc-rust.zulipchat.com/), which provides a jitsi integration to
> facilitate the video call. I want to invite people from the GCC
> community to join if they wish.
>
> These monthly calls have associated meeting notes for those who cannot
> attend. Here is an example from our last meeting:
>
> https://github.com/Rust-GCC/Reporting/blob/main/2021-05-07-community-call.md
>
> The agenda for this next call is currently being set up in a
> collaborative document here: https://hackmd.io/rBFlwl_9TkWLox-X6jyxDg
>
> Please find the monthly report for May 2021 for more information:
> https://github.com/Rust-GCC/Reporting/blob/main/2021-05-monthly-report.org
>
> Thanks
>
> --Phil
>
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Test results for gccrs on Debian unstable aarch64

[Philip Herron]

I just had a thought it would be nice if we could keep a matrix of
different platforms gccrs has been tested on, and they could have states of:

1. Build Failure
2. Test Failures link to log
3. Tests pass, no unexpected results

What if we maintained a section in the wiki for this?

Thanks,

--Phil

On Thu, 3 Jun 2021 at 12:28, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hi!
>
> Just built revision 324dfb828cec09f7638b48b6e25e4007b45b9cbc on Debian
> unstable aarch64.
>
> Testsuite passes without any issues, attaching the full log.
>
> Adrian
>
> === rust tests ===
>
> Schedule of variations:
> unix
>
> Running target unix
> Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
> target.
> Using /usr/share/dejagnu/config/unix.exp as generic interface file for
> target.
> Using /home/glaubitz/gccrs/gcc/testsuite/config/default.exp as
> tool-and-target-specific interface file.
> Running /home/glaubitz/gccrs/gcc/testsuite/rust/compile/compile.exp ...
> Running
> /home/glaubitz/gccrs/gcc/testsuite/rust/compile/torture/compile.exp ...
> Running /home/glaubitz/gccrs/gcc/testsuite/rust/compile/xfail/xfail.exp ...
> Running
> /home/glaubitz/gccrs/gcc/testsuite/rust/execute/torture/execute.exp ...
>
> === rust Summary ===
>
> # of expected passes2368
> # of expected failures  26
> make[2]: Leaving directory '/home/glaubitz/gccrs/build/gcc'
> make[1]: Leaving directory '/home/glaubitz/gccrs/build/gcc'
>
> --
>  .''`.  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: Test results for gccrs on Debian unstable aarch64

[Philip Herron]

That's likely a better solution. In fact, I started looking at that a while
back, but I haven't test/finished it:

```
language: c

arch:
  - amd64
  - ppc64le
  - s390x
  - arm64

os: linux

before_install:
  - sudo apt-get install -y automake autoconf libtool autogen bison flex
libgmp3-dev libmpfr-dev libmpc-dev build-essential gcc-multilib
g++-multilib dejagnu

script:
  - mkdir -p gccrs-build;
  - cd gccrs-build; ../configure --enable-languages=rust
--disable-bootstrap --enable-multilib; make -j $(nproc); make check-rust
  - cd gccrs-build; \
   if grep "# of unexpected" gcc/testsuite/rust/rust.sum;\
   then \
  echo "some tests are not correct"; \
  exit 1; \
else \
  exit 0; \
fi

```

I might make an issue out of this, in the hopes someone can test and fix up
this initial travis.yml.

--Phil

On Thu, 3 Jun 2021 at 13:05, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hi Phil!
>
> On 6/3/21 1:58 PM, Philip Herron wrote:
> > I just had a thought it would be nice if we could keep a matrix of
> > different platforms gccrs has been tested on, and they could have states
> of:
> >
> > 1. Build Failure
> > 2. Test Failures link to log
> > 3. Tests pass, no unexpected results
> >
> > What if we maintained a section in the wiki for this?
> Sounds like a great idea. I think another idea would be to set up Travis
> which
> has support for a couple of architectures such as aarch64 and ppc64le.
>
> I'm not planning to keep repeating this manual build and testsuite runs,
> but I
> just want to get familiar with the project and fix some minor portability
> issues
> while I'm at it.
>
> I'm also particularly interested to see how well gccrs already works on
> various
> architectures. Getting Rust to work on more targets is very important for
> Debian
> as we have some architectures which are currently falling behind due to
> the lack
> of platform support in rustc.
>
> 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: GCC Rust monthly call

[Philip Herron]

Hi everyone,

For those interested, you find the meeting notes of our call over on:
https://github.com/Rust-GCC/Reporting/blob/main/2021-06-04-community-call.md

Thanks,

--Phil

On Thu, 3 Jun 2021 at 12:33, Philip Herron 
wrote:

> Hi everyone,
>
> Just a reminder that tomorrow is the community call: at 10am utc+1. The
> agenda so far is detailed within: https://hackmd.io/rBFlwl_9TkWLox-X6jyxDg
>
> The call will be hosted on Jitsi, here is the link we will use:
> https://meet.jit.si/259057065581073
>
> Thanks
>
> --Phil
>
> On Mon, 31 May 2021 at 12:48, Philip Herron 
> wrote:
>
>> Hello,
>>
>> On the first Friday of every month, GCC Rust has a community call. The
>> next one will be on the 4th of June 2021, at 10am utc+1 (I am based in
>> Northern Ireland). We use our zulip server
>> (https://gcc-rust.zulipchat.com/), which provides a jitsi integration to
>> facilitate the video call. I want to invite people from the GCC
>> community to join if they wish.
>>
>> These monthly calls have associated meeting notes for those who cannot
>> attend. Here is an example from our last meeting:
>>
>> https://github.com/Rust-GCC/Reporting/blob/main/2021-05-07-community-call.md
>>
>> The agenda for this next call is currently being set up in a
>> collaborative document here: https://hackmd.io/rBFlwl_9TkWLox-X6jyxDg
>>
>> Please find the monthly report for May 2021 for more information:
>> https://github.com/Rust-GCC/Reporting/blob/main/2021-05-monthly-report.org
>>
>> Thanks
>>
>> --Phil
>>
>>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: GCC Rust monthly call

[Philip Herron]

I think my email with the time is not very clear which doesn't help. I will
maybe copy how the risc-v guys put their status report call email out with
examples of timezones and the simple UTC time.

Have a great day, The next one will be 2nd of July 2021, these meetings are
on the first Friday of the month.

--Phil

On Fri, 4 Jun 2021 at 11:49, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 6/4/21 12:47 PM, Philip Herron wrote:
> > For those interested, you find the meeting notes of our call over on:
> >
> https://github.com/Rust-GCC/Reporting/blob/main/2021-06-04-community-call.md
>
> Ah, dang, I missed the call. I somehow thought it would be in the evening
> :|.
>
> Next time then.
>
> 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: Test results for gccrs on Debian unstable sh4

[Philip Herron]

On Thu, 10 Jun 2021 at 02:49, Oleg Endo  wrote:

> On Wed, 2021-06-09 at 15:49 +0200, John Paul Adrian Glaubitz wrote:
> > Hi!
> >
> > Just built revision ff4715d79e2c17d270db8b94315aa6b574f48994 on Debian
> unstable sh4
> > (SuperH) on my Renesas SH-7785LCR evaluation board.
> >
> > Testsuite passes without any issues, attaching the full log.
> >
> > CC'ing two SuperH-related mailing list in case someone is interested.
> >
> > Adrian
> > === rust tests ===
> >
> > Schedule of variations:
> > unix
> >
> > Running target unix
> > Using /usr/share/dejagnu/baseboards/unix.exp as board description file
> for target.
> > Using /usr/share/dejagnu/config/unix.exp as generic interface file for
> target.
> > Using /srv/glaubitz/gccrs/gcc/testsuite/config/default.exp as
> tool-and-target-specific interface file.
> > Running /srv/glaubitz/gccrs/gcc/testsuite/rust/compile/compile.exp ...
> > Running
> /srv/glaubitz/gccrs/gcc/testsuite/rust/compile/torture/compile.exp ...
> > Running /srv/glaubitz/gccrs/gcc/testsuite/rust/compile/xfail/xfail.exp
> ...
> > Running
> /srv/glaubitz/gccrs/gcc/testsuite/rust/execute/torture/execute.exp ...
> >
> > === rust Summary ===
> >
> > # of expected passes2415
> > # of expected failures  15
> > make[2]: Leaving directory '/srv/glaubitz/gccrs/build/gcc'
> > make[1]: Leaving directory '/srv/glaubitz/gccrs/build/gcc'
> >
>
>
> Nice! Thanks for your efforts, Adrian!
>
> Cheers,
> Oleg
>
> --
> Gcc-rust mailing list
> Gcc-rust@gcc.gnu.org
> https://gcc.gnu.org/mailman/listinfo/gcc-rust


This is pretty neat, what was it like to compile GCC on that board?

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

Re: tuple indexes

[Philip Herron]

On 22/06/2021 23:51, Mark Wielaard wrote:
> Hi,
>
> I was looking into https://github.com/Rust-GCC/gccrs/issues/511 "rust
> has two kinds of integer literal" Which explains that integer literals
> used for a tuple index are not general integer literals.
>
> First I wanted to write some tests, and started with some constructs
> that should pass. But some don't. In particular the empty tuple struct
> isn't recognized, and the struct name path lookup doesn't work when
> initializing the tuple struct.
>
> tuple_index.rs:16:12: error: unrecognised token ‘)’ in type
>16 |   struct E();
>   |^
> tuple_index.rs:16:12: error: could not parse type in tuple struct field
>
> tuple_index.rs:20:12: error: unknown root segment in path O lookup O
>20 |   let so = O(0);
>   |^
> tuple_index.rs:24:12: error: unknown root segment in path T lookup T
>24 |   let st = T(0,1);
>   |^
> tuple_index.rs:28:12: error: unknown root segment in path M lookup M
>28 |   let sm = M(0,1,2,3,4,5,6,7,8,9,10);
>   |^
>
> I haven't had time to try to resolve these issues, but wanted to
> report them.
>
> Finally, the The Rust Reference says "A tuple index is used to refer
> to the fields of tuples, tuple structs, and tuple variants." I don't
> understand how this would work for tuple variants. Does anybody have
> an example of how to refer to a tuple variant so a tuple index can be
> used on it?
>
> Cheers,
>
> Mark
>
Hi Mark,

Good find, I have raised https://github.com/Rust-GCC/gccrs/issues/519.
From the top of my head I think there are a few issues going on.

1. The parser is not able to parse the structure definitions within a
block properly.

2. The knock on is that the name resolution and type resolution will
need updated to handle this.

I think I might take a quick look into this one today I want to double
check a few things as it may have a knock on as to what I am working on.
If i make any progress I will update the ticket and let you know here.

Thanks,

--Phil




OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: tuple indexes

[Philip Herron]

On 23/06/2021 10:47, Philip Herron wrote:
> On 22/06/2021 23:51, Mark Wielaard wrote:
>> Hi,
>>
>> I was looking into https://github.com/Rust-GCC/gccrs/issues/511 "rust
>> has two kinds of integer literal" Which explains that integer literals
>> used for a tuple index are not general integer literals.
>>
>> First I wanted to write some tests, and started with some constructs
>> that should pass. But some don't. In particular the empty tuple struct
>> isn't recognized, and the struct name path lookup doesn't work when
>> initializing the tuple struct.
>>
>> tuple_index.rs:16:12: error: unrecognised token ‘)’ in type
>>16 |   struct E();
>>   |^
>> tuple_index.rs:16:12: error: could not parse type in tuple struct field
>>
>> tuple_index.rs:20:12: error: unknown root segment in path O lookup O
>>20 |   let so = O(0);
>>   |^
>> tuple_index.rs:24:12: error: unknown root segment in path T lookup T
>>24 |   let st = T(0,1);
>>   |^
>> tuple_index.rs:28:12: error: unknown root segment in path M lookup M
>>28 |   let sm = M(0,1,2,3,4,5,6,7,8,9,10);
>>   |^
>>
>> I haven't had time to try to resolve these issues, but wanted to
>> report them.
>>
>> Finally, the The Rust Reference says "A tuple index is used to refer
>> to the fields of tuples, tuple structs, and tuple variants." I don't
>> understand how this would work for tuple variants. Does anybody have
>> an example of how to refer to a tuple variant so a tuple index can be
>> used on it?
>>
>> Cheers,
>>
>> Mark
>>
> Hi Mark,
>
> Good find, I have raised https://github.com/Rust-GCC/gccrs/issues/519.
> From the top of my head I think there are a few issues going on.
>
> 1. The parser is not able to parse the structure definitions within a
> block properly.
>
> 2. The knock on is that the name resolution and type resolution will
> need updated to handle this.
>
> I think I might take a quick look into this one today I want to double
> check a few things as it may have a knock on as to what I am working on.
> If i make any progress I will update the ticket and let you know here.
>
> Thanks,
>
> --Phil
>
Small update, I think part of this issue is that the support for
unit-structs is not there yet in the compiler, so if you remove the unit
tuple struct and move the other struct definitions outside of the block
the test case works: https://godbolt.org/z/nb84sEaE4

It might be enough to help with testing your tuple index fixes.

Thanks

--Phil




OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: tuple indexes

[Philip Herron]

On 23/06/2021 17:06, Mark Wielaard wrote:
> Hi Philip,
>
> On Wed, 2021-06-23 at 10:55 +0100, Philip Herron wrote:
>> Small update, I think part of this issue is that the support for
>> unit-structs is not there yet in the compiler, so if you remove the unit
>> tuple struct and move the other struct definitions outside of the block
>> the test case works: https://godbolt.org/z/nb84sEaE4
>>
>> It might be enough to help with testing your tuple index fixes.
> Very nice. That workaround helps me get unblocked, except for testing
> empty struct tuples (unit-structs). But I have a patch for that, and
> even included a testcase to proof the parser now handles them. See
> attached.
>
> Cheers,
>
> Mark

This was a good find. Your patch is now being merged:
https://github.com/Rust-GCC/gccrs/pull/521

Thanks

--Phil




OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: tuple indexes

[Philip Herron]

On 23/06/2021 21:15, Mark Wielaard wrote:
> On Wed, Jun 23, 2021 at 12:51:34AM +0200, Mark Wielaard wrote:
>> Finally, the The Rust Reference says "A tuple index is used to refer
>> to the fields of tuples, tuple structs, and tuple variants." I don't
>> understand how this would work for tuple variants. Does anybody have
>> an example of how to refer to a tuple variant so a tuple index can be
>> used on it?
> Tom pointed out on irc that it doesn't seem possible to access enum
> variant types except through a matching expression. The Rust Reference
> also seems to be inconsistent. As mentioned above it mentions you can
> use a tuple index to refer to a field of a enum tuple variant. But it
> also says "A tuple indexing expression accesses fields of tuples and
> tuple structs." So it probably really isn't possible to use a tuple
> index on enum tuple variants.
>
> I did notice the same issue as for unit tuple struct types. The empty
> tuple wasn't accepted in the parser. The attached patch, also at
> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=tuple_enum_variant_unit
> fixes this.
>
> It does include a test case, but most of it is commented out because
> actually resolving enum types isn't implemented yet. If you uncomment
> the rest of the testcase you get:
>
> tuple_enum_variants.rs:3:31: error: failed to resolve TypePath: E
> 3 | fn f(e0: E, e1: E, e2: E) -> (E,E,E,())
>   |   ^
> tuple_enum_variants.rs:3:31: error: unresolved type
> tuple_enum_variants.rs:3:33: error: failed to resolve TypePath: E
> 3 | fn f(e0: E, e1: E, e2: E) -> (E,E,E,())
>   | ^
> tuple_enum_variants.rs:3:33: error: unresolved type
> tuple_enum_variants.rs:3:35: error: failed to resolve TypePath: E
> 3 | fn f(e0: E, e1: E, e2: E) -> (E,E,E,())
>   |   ^
> tuple_enum_variants.rs:3:35: error: unresolved type
> tuple_enum_variants.rs:3:10: error: failed to resolve TypePath: E
> 3 | fn f(e0: E, e1: E, e2: E) -> (E,E,E,())
>   |  ^
> tuple_enum_variants.rs:3:10: error: unresolved type
> tuple_enum_variants.rs:3:17: error: failed to resolve TypePath: E
> 3 | fn f(e0: E, e1: E, e2: E) -> (E,E,E,())
>   | ^
> tuple_enum_variants.rs:3:17: error: unresolved type
> tuple_enum_variants.rs:3:24: error: failed to resolve TypePath: E
> 3 | fn f(e0: E, e1: E, e2: E) -> (E,E,E,())
>   |^
> tuple_enum_variants.rs:3:24: error: unresolved type
> tuple_enum_variants.rs:13:12: error: unknown root segment in path E::T0 
> lookup E
>13 |   let e0 = E::T0();
>   |^
> tuple_enum_variants.rs:14:12: error: unknown root segment in path E::T1 
> lookup E
>14 |   let e1 = E::T1(0);
>   |^
> tuple_enum_variants.rs:15:12: error: unknown root segment in path E::T2 
> lookup E
>15 |   let e2 = E::T2(0,1);
>   |^
>
> Cheers,
>
> Mark
>
Hi Mark,

Thanks for the patch, its being merged:
https://github.com/Rust-GCC/gccrs/pull/522

I have open issues about enums and unions they will be fixed as part of
my work into traits. They are a type of algebraic data type so in theory
i can reuse a lot of the existing code to implement them.

Thanks

--Phil




OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

GCC Rust Monthly Call - 2nd July 2021

[Philip Herron]

Hi everyone,

It is that time again and we will be having our 4th community call over
on Jitsi for the first Friday of the month.

  * Date: 2nd July 2021
  o UTC: 0900
  o UK/Ireland UTC+1/BST: 1000
  o Central European Summer Time UTC+2: 1100
  * Monthly Report: WIP
  * Agenda (WIP): https://hackmd.io/A-b-G90YTNSCEVjiHXz7Qg

  * Jitsi video call: https://meet.jit.si/259057065581073


Here is the latest weekly report for the project:
https://github.com/Rust-GCC/Reporting/blob/main/2021-06-21-report.org

Please feel free to suggest any topics/questions you wish to be
discussed here or directly onto the agenda hackmd document.

Thanks

--Phil



OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Unit Type for Rust

[Philip Herron]

Hi everyone,

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

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:

```
In function ‘test’:
rust1: internal compiler error: in create_tmp_var, at gimple-expr.c:482
0x13fd3bf create_tmp_var(tree_node*, char const*)
    ../../gccrs/gcc/gimple-expr.c:482
0xe5d195 Gcc_backend::temporary_variable(Bfunction*, Bblock*, Btype*,
Bexpression*, bool, Location, Bstatement**)
    ../../gccrs/gcc/rust/rust-gcc.cc:2889
0xfe3479 Rust::HIR::Function::accept_vis(Rust::HIR::HIRVisitor&)
    ../../gccrs/gcc/rust/hir/tree/rust-hir-full-test.cc:4414
0xf95cdb Rust::Compile::CompileCrate::go()
    ../../gccrs/gcc/rust/backend/rust-compile.cc:49
0xf95b8b Rust::Compile::CompileCrate::Compile(Rust::HIR::Crate&,
Rust::Compile::Context*)
    ../../gccrs/gcc/rust/backend/rust-compile.cc:39
0xee92e7 Rust::Session::parse_file(char const*)
    ../../gccrs/gcc/rust/rust-session-manager.cc:596
0xee8d76 Rust::Session::parse_files(int, char const**)
    ../../gccrs/gcc/rust/rust-session-manager.cc:459
0xe45264 grs_langhook_parse_file
    ../../gccrs/gcc/rust/rust-lang.cc:171

```

I think because void_node is likely not COMPLETE_TYPE_P which means it
hits the assertion when you need temporary's.


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
  16 | fn main() {
 | ^
   0x1d551d5 wi::min_value(unsigned int, signop)
   ../../gccrs/gcc/wide-int.cc:346
   0x1146ca5 irange::set_varying(tree_node*)
   ../../gccrs/gcc/value-range.h:476
   0x1ce5970 value_range_equiv::set_varying(tree_node*)
   ../../gccrs/gcc/value-range-equiv.cc:71
   0x1d3da07 vr_values::set_def_to_varying(tree_node const*)
   ../../gccrs/gcc/vr-values.c:230
   0x1d3da70 vr_values::set_defs_to_varying(gimple*)
   ../../gccrs/gcc/vr-values.c:241
   0x1c78b2f vrp_prop::visit_stmt(gimple*, edge_def**, tree_node**)
   ../../gccrs/gcc/tree-vrp.c:4001
   0x1ad8519 ssa_propagation_engine::simulate_stmt(gimple*)
   ../../gccrs/gcc/tree-ssa-propagate.c:230
   0x1ad8a0e ssa_propagation_engine::simulate_block(basic_block_def*)
   ../../gccrs/gcc/tree-ssa-propagate.c:337
   0x1ad9f2e ssa_propagation_engine::ssa_propagate()
   ../../gccrs/gcc/tree-ssa-propagate.c:800
   0x1c7a0b0 execute_vrp
   ../../gccrs/gcc/tree-vrp.c:4512
   0x1c7a3e4 execute
   ../../gccrs/gcc/tree-vrp.c:4620
   Please submit a full bug report,
   ```

The backtrace looks as though the optimizer is looking for min value for
a default for the return value, but it's a zero precision integer that
hits the assertion. Note running with -O0, the assertion does not get hit.


At the moment, I have left functions with return type unit to keep using
void_type_node and everywhere else, use this new zero precision integer.
I am not sure what the best approach is here; I was hoping to solicit
feedback on what I am doing with the folks here on the mailing list.

Thanks

--Phil


OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Unit Type for Rust

[Philip Herron]

On 28/06/2021 14:49, Philip Herron wrote:
> Hi everyone,
>
> 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
>
> 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:
>
> ```
> In function ‘test’:
> rust1: internal compiler error: in create_tmp_var, at gimple-expr.c:482
> 0x13fd3bf create_tmp_var(tree_node*, char const*)
>     ../../gccrs/gcc/gimple-expr.c:482
> 0xe5d195 Gcc_backend::temporary_variable(Bfunction*, Bblock*, Btype*,
> Bexpression*, bool, Location, Bstatement**)
>     ../../gccrs/gcc/rust/rust-gcc.cc:2889
> 0xfe3479 Rust::HIR::Function::accept_vis(Rust::HIR::HIRVisitor&)
>     ../../gccrs/gcc/rust/hir/tree/rust-hir-full-test.cc:4414
> 0xf95cdb Rust::Compile::CompileCrate::go()
>     ../../gccrs/gcc/rust/backend/rust-compile.cc:49
> 0xf95b8b Rust::Compile::CompileCrate::Compile(Rust::HIR::Crate&,
> Rust::Compile::Context*)
>     ../../gccrs/gcc/rust/backend/rust-compile.cc:39
> 0xee92e7 Rust::Session::parse_file(char const*)
>     ../../gccrs/gcc/rust/rust-session-manager.cc:596
> 0xee8d76 Rust::Session::parse_files(int, char const**)
>     ../../gccrs/gcc/rust/rust-session-manager.cc:459
> 0xe45264 grs_langhook_parse_file
>     ../../gccrs/gcc/rust/rust-lang.cc:171
>
> ```
>
> I think because void_node is likely not COMPLETE_TYPE_P which means it
> hits the assertion when you need temporary's.
>
>
> 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
>   16 | fn main() {
>  | ^
>    0x1d551d5 wi::min_value(unsigned int, signop)
>    ../../gccrs/gcc/wide-int.cc:346
>    0x1146ca5 irange::set_varying(tree_node*)
>    ../../gccrs/gcc/value-range.h:476
>    0x1ce5970 value_range_equiv::set_varying(tree_node*)
>    ../../gccrs/gcc/value-range-equiv.cc:71
>    0x1d3da07 vr_values::set_def_to_varying(tree_node const*)
>    ../../gccrs/gcc/vr-values.c:230
>    0x1d3da70 vr_values::set_defs_to_varying(gimple*)
>    ../../gccrs/gcc/vr-values.c:241
>    0x1c78b2f vrp_prop::visit_stmt(gimple*, edge_def**, tree_node**)
>    ../../gccrs/gcc/tree-vrp.c:4001
>    0x1ad8519 ssa_propagation_engine::simulate_stmt(gimple*)
>    ../../gccrs/gcc/tree-ssa-propagate.c:230
>    0x1ad8a0e ssa_propagation_engine::simulate_block(basic_block_def*)
>    ../../gccrs/gcc/tree-ssa-propagate.c:337
>    0x1ad9f2e ssa_propagation_engine::ssa_propagate()
>    ../../gccrs/gcc/tree-ssa-propagate.c:800
>    0x1c7a0b0 execute_vrp
>    ../../gccrs/gcc/tree-vrp.c:4512
>    0x1c7a3e4 execute
>    ../../gccrs/gcc/tree-vrp.c:4620
>    Please submit a full bug report,
>    ```
>
> The backtrace looks as though the optimizer is looking for min value for
> a default for the return value, but it's a zero precision integer that
> hits the assertion. Note running with -O0, the assertion does not get hit.
>
>
> At the moment, I have left functions with return type unit to keep using
> void_type_node and everywhere else, use this new zero precision integer.
> I am not sure what the best approach is here; I was hoping to solicit
> feedback on what I am doing with the folks here on the mailing list.
>
> Thanks
>
> --Phil
>

Adding in the GCC mailing list for feedback.

Thanks

--Phil



OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: GCC Rust Monthly Call - 2nd July 2021

[Philip Herron]

Hi everyone,

Please find the meeting notes for our call over on:
https://github.com/Rust-GCC/Reporting/blob/main/2021-07-02-community-call.md

Thanks again

--Phil

On Mon, 28 Jun 2021 at 12:33, Philip Herron 
wrote:

> Hi everyone,
>
> It is that time again and we will be having our 4th community call over on
> Jitsi for the first Friday of the month.
>
>- Date: 2nd July 2021
>   - UTC: 0900
>   - UK/Ireland UTC+1/BST: 1000
>   - Central European Summer Time UTC+2: 1100
>- Monthly Report: WIP
>- Agenda (WIP): https://hackmd.io/A-b-G90YTNSCEVjiHXz7Qg
>- Jitsi video call: https://meet.jit.si/259057065581073
>
> Here is the latest weekly report for the project:
> https://github.com/Rust-GCC/Reporting/blob/main/2021-06-21-report.org
>
> Please feel free to suggest any topics/questions you wish to be discussed
> here or directly onto the agenda hackmd document.
>
> Thanks
>
> --Phil
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH] Handle doc comment strings in lexer and parser

[Philip Herron]

On 11/07/2021 21:10, Mark Wielaard wrote:
> Remove (unused) comment related tokens and replace them with
> INNER_DOC_COMMENT and OUTER_DOC_COMMENT tokens, which keep the comment
> text as a string. These can be constructed with the new
> make_inner_doc_comment and make_outer_doc_comment methods.
>
> Make sure to not confuse doc strings with normal comments in the lexer
> when detecting shebang lines. Both single line //! and /*! */ blocks
> are turned into INNER_DOC_COMMENT tokens. And both single line /// and
> /** */ blocks are turned into OUTER_DOC_COMMENT tokens.
>
> Also fixes some issues with cr/lf line endings and keeping the line
> map correct when seeing \n in a comment.
>
> In the parser handle INNER_DOC_COMMENT and OUTER_DOC_COMMENTS where
> inner (#[]) and outer (#![]) attributes are handled. Add a method
> parse_doc_comment which turns the tokens into an "doc" Attribute with
> the string as literal expression.
>
> Add get_locus method to Attribute class for better error reporting.
>
> Tests are added for correctly placed and formatted doc strings, with
> or without cr/lf line endings. Incorrect formatted (isolated CRs) doc
> strings and badly placed inner doc strings. No tests add handling of
> the actual doc attributes yet. These could be tested once we add
> support for the #![warn(missing_docs)] attribute.
> ---
>  gcc/rust/ast/rust-ast.h   |   2 +
>  gcc/rust/lex/rust-lex.cc  | 214 --
>  gcc/rust/lex/rust-token.h |  25 +-
>  gcc/rust/parse/rust-parse-impl.h  |  60 -
>  gcc/rust/parse/rust-parse.h   |   1 +
>  gcc/testsuite/rust/compile/bad_inner_doc.rs   |  15 ++
>  .../compile/doc_isolated_cr_block_comment.rs  |   3 +
>  .../doc_isolated_cr_inner_block_comment.rs|   5 +
>  .../doc_isolated_cr_inner_line_comment.rs |   5 +
>  .../compile/doc_isolated_cr_line_comment.rs   |   3 +
>  .../torture/all_doc_comment_line_blocks.rs|  47 
>  .../all_doc_comment_line_blocks_crlf.rs   |  47 
>  .../torture/isolated_cr_block_comment.rs  |   2 +
>  .../torture/isolated_cr_line_comment.rs   |   2 +
>  14 files changed, 401 insertions(+), 30 deletions(-)
>  create mode 100644 gcc/testsuite/rust/compile/bad_inner_doc.rs
>  create mode 100644 
> gcc/testsuite/rust/compile/doc_isolated_cr_block_comment.rs
>  create mode 100644 
> gcc/testsuite/rust/compile/doc_isolated_cr_inner_block_comment.rs
>  create mode 100644 
> gcc/testsuite/rust/compile/doc_isolated_cr_inner_line_comment.rs
>  create mode 100644 gcc/testsuite/rust/compile/doc_isolated_cr_line_comment.rs
>  create mode 100644 
> gcc/testsuite/rust/compile/torture/all_doc_comment_line_blocks.rs
>  create mode 100644 
> gcc/testsuite/rust/compile/torture/all_doc_comment_line_blocks_crlf.rs
>  create mode 100644 
> gcc/testsuite/rust/compile/torture/isolated_cr_block_comment.rs
>  create mode 100644 
> gcc/testsuite/rust/compile/torture/isolated_cr_line_comment.rs
>
> diff --git a/gcc/rust/ast/rust-ast.h b/gcc/rust/ast/rust-ast.h
> index 75b08f8aa66..3e3e185b9b5 100644
> --- a/gcc/rust/ast/rust-ast.h
> +++ b/gcc/rust/ast/rust-ast.h
> @@ -455,6 +455,8 @@ public:
>// Returns whether the attribute is considered an "empty" attribute.
>bool is_empty () const { return attr_input == nullptr && path.is_empty (); 
> }
>  
> +  Location get_locus () const { return locus; }
> +
>/* e.g.:
>#![crate_type = "lib"]
>#[test]
> diff --git a/gcc/rust/lex/rust-lex.cc b/gcc/rust/lex/rust-lex.cc
> index 617dd69a080..0b8a8eae651 100644
> --- a/gcc/rust/lex/rust-lex.cc
> +++ b/gcc/rust/lex/rust-lex.cc
> @@ -265,9 +265,16 @@ Lexer::build_token ()
> int next_char = peek_input (n);
> if (is_whitespace (next_char))
>   n++;
> -   else if (next_char == '/' && peek_input (n + 1) == '/')
> +   else if ((next_char == '/' && peek_input (n + 1) == '/'
> + && peek_input (n + 2) != '!'
> + && peek_input (n + 2) != '/')
> +|| (next_char == '/' && peek_input (n + 1) == '/'
> +&& peek_input (n + 2) == '/'
> +&& peek_input (n + 3) == '/'))
>   {
> +   // two // or four 
> // A single line comment
> +   // (but not an inner or outer doc comment)
> n += 2;
> next_char = peek_input (n);
> while (next_char != '\n' && next_char != EOF)
> @@ -278,9 +285,30 @@ Lexer::build_token ()
> if (next_char == '\n')
>   n++;
>   }
> -   else if (next_char == '/' && peek_input (n + 1) == '*')
> +   else if (next_char == '/' && peek_input (n + 1) == '*'
> +&& peek_input (n + 2) == '*'
> +&& peek_input (n + 3) == '/')
>   {
> +   /**/
> +   n += 4;
> + 

Re: [PATCH] Remove HIR MacroItem and other hir macro forward declarations

[Philip Herron]

On 11/07/2021 22:39, Mark Wielaard wrote:
> Almost all HIR Macro related trees were already removed by
> https://github.com/Rust-GCC/gccrs/pull/492
>
> But there was still one MacroItem class left in rust-hir.h and several
> (unused) forward declarations in various other hir .h files. Remove
> them all.
>
> Resolves: https://github.com/Rust-GCC/gccrs/issues/69
> ---
>  gcc/rust/hir/tree/rust-hir-expr.h|  3 ---
>  gcc/rust/hir/tree/rust-hir-item.h|  3 ---
>  gcc/rust/hir/tree/rust-hir-pattern.h |  2 --
>  gcc/rust/hir/tree/rust-hir-type.h|  3 ---
>  gcc/rust/hir/tree/rust-hir.h | 11 ---
>  5 files changed, 22 deletions(-)
>
> diff --git a/gcc/rust/hir/tree/rust-hir-expr.h 
> b/gcc/rust/hir/tree/rust-hir-expr.h
> index 681ccf8ad65..2b1e9380f6c 100644
> --- a/gcc/rust/hir/tree/rust-hir-expr.h
> +++ b/gcc/rust/hir/tree/rust-hir-expr.h
> @@ -3094,9 +3094,6 @@ protected:
>}
>  };
>  
> -// Forward decl - defined in rust-macro.h
> -class MacroInvocation;
> -
>  // An unsafe block HIR node
>  class UnsafeBlockExpr : public ExprWithBlock
>  {
> diff --git a/gcc/rust/hir/tree/rust-hir-item.h 
> b/gcc/rust/hir/tree/rust-hir-item.h
> index 10b1f6143f0..e7e110fda92 100644
> --- a/gcc/rust/hir/tree/rust-hir-item.h
> +++ b/gcc/rust/hir/tree/rust-hir-item.h
> @@ -3020,9 +3020,6 @@ protected:
>}*/
>  };
>  
> -// Replaced with forward decls - defined in "rust-macro.h"
> -class MacroItem;
> -class MacroRulesDefinition;
>  } // namespace HIR
>  } // namespace Rust
>  
> diff --git a/gcc/rust/hir/tree/rust-hir-pattern.h 
> b/gcc/rust/hir/tree/rust-hir-pattern.h
> index 27cba7d6e18..ac7155d562f 100644
> --- a/gcc/rust/hir/tree/rust-hir-pattern.h
> +++ b/gcc/rust/hir/tree/rust-hir-pattern.h
> @@ -1152,8 +1152,6 @@ class PathPattern;
>  class PathInExpression;
>  class QualifiedPathInExpression;
>  
> -// Replaced with forward decl - defined in rust-macro.h
> -class MacroInvocation;
>  } // namespace HIR
>  } // namespace Rust
>  
> diff --git a/gcc/rust/hir/tree/rust-hir-type.h 
> b/gcc/rust/hir/tree/rust-hir-type.h
> index 42fccb59607..c4771b6db38 100644
> --- a/gcc/rust/hir/tree/rust-hir-type.h
> +++ b/gcc/rust/hir/tree/rust-hir-type.h
> @@ -907,9 +907,6 @@ protected:
>}
>  };
>  
> -// Forward decl - defined in rust-macro.h
> -class MacroInvocation;
> -
>  /* TODO: possible types
>   * struct type?
>   * "enum" (tagged union) type?
> diff --git a/gcc/rust/hir/tree/rust-hir.h b/gcc/rust/hir/tree/rust-hir.h
> index 1819d17b585..7d53feb0a4e 100644
> --- a/gcc/rust/hir/tree/rust-hir.h
> +++ b/gcc/rust/hir/tree/rust-hir.h
> @@ -613,17 +613,6 @@ protected:
>}
>  };
>  
> -// A macro item HIR node - potentially abstract base class
> -class MacroItem : public Item
> -{
> -  /*public:
> -  std::string as_string() const;*/
> -protected:
> -  MacroItem (Analysis::NodeMapping mappings, AST::AttrVec outer_attribs)
> -: Item (std::move (mappings), std::move (outer_attribs))
> -  {}
> -};
> -
>  // Item used in trait declarations - abstract base class
>  class TraitItem
>  {

Hi Mark,

Thanks for this, I missed these tree's in my last cleanup. This is
currently being merged: https://github.com/Rust-GCC/gccrs/pull/560

Thanks

--Phil





OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH] Handle doc comment strings in lexer and parser

[Philip Herron]

On 12/07/2021 09:32, Mark Wielaard wrote:
> Hi Philip,
>
> On Mon, Jul 12, 2021 at 09:09:09AM +0100, Philip Herron wrote:
>> This patch looks good to me. When I tried to apply it to merge it I got
>> the following:
>>
>> ```
>> $ git am  '[PATCH] Handle doc comment strings in lexer and parser.eml'
>> Applying: Handle doc comment strings in lexer and parser
>> error: corrupt patch at line 531
>> Patch failed at 0001 Handle doc comment strings in lexer and parser
>> hint: Use 'git am --show-current-patch' to see the failed patch
>> When you have resolved this problem, run "git am --continue".
>> If you prefer to skip this patch, run "git am --skip" instead.
>> To restore the original branch and stop patching, run "git am --abort".
>> ```
>>
>> Not sure if I have done something wrong, have you any pointers?
> Looks like that is one of the IsolatedCR tests (a bare \r not at the
> end of a line followed by \n in a doc comment string). I assume some
> mailer ate it and/or added a \n somehwere to "correct" it.
>
> Would you be able to pull directly from my git repo?
>
> The following changes since commit 4560f469ee33536cec6af0f8e5816ff97de60de0:
>
>   Merge #551 (2021-07-10 21:02:06 +)
>
> are available in the Git repository at:
>
>   https://code.wildebeest.org/git/user/mjw/gccrs doc-comments
>
> for you to fetch changes up to e1e14958a90397a1ed6ab7236dc5a6f1c2f22505:
>
>   Handle doc comment strings in lexer and parser (2021-07-11 21:09:21 +0200)
>
> 
> Mark Wielaard (1):
>   Handle doc comment strings in lexer and parser
>
>  gcc/rust/ast/rust-ast.h|   2 +
>  gcc/rust/lex/rust-lex.cc   | 214 
> +++--
>  gcc/rust/lex/rust-token.h  |  25 ++-
>  gcc/rust/parse/rust-parse-impl.h   |  60 +-
>  gcc/rust/parse/rust-parse.h|   1 +
>  gcc/testsuite/rust/compile/bad_inner_doc.rs|  15 ++
>  .../rust/compile/doc_isolated_cr_block_comment.rs  |   3 +
>  .../compile/doc_isolated_cr_inner_block_comment.rs |   5 +
>  .../compile/doc_isolated_cr_inner_line_comment.rs  |   5 +
>  .../rust/compile/doc_isolated_cr_line_comment.rs   |   3 +
>  .../compile/torture/all_doc_comment_line_blocks.rs |  47 +
>  .../torture/all_doc_comment_line_blocks_crlf.rs|  47 +
>  .../compile/torture/isolated_cr_block_comment.rs   |   2 +
>  .../compile/torture/isolated_cr_line_comment.rs|   2 +
>  14 files changed, 401 insertions(+), 30 deletions(-)
>  create mode 100644 gcc/testsuite/rust/compile/bad_inner_doc.rs
>  create mode 100644 
> gcc/testsuite/rust/compile/doc_isolated_cr_block_comment.rs
>  create mode 100644 
> gcc/testsuite/rust/compile/doc_isolated_cr_inner_block_comment.rs
>  create mode 100644 
> gcc/testsuite/rust/compile/doc_isolated_cr_inner_line_comment.rs
>  create mode 100644 gcc/testsuite/rust/compile/doc_isolated_cr_line_comment.rs
>  create mode 100644 
> gcc/testsuite/rust/compile/torture/all_doc_comment_line_blocks.rs
>  create mode 100644 
> gcc/testsuite/rust/compile/torture/all_doc_comment_line_blocks_crlf.rs
>  create mode 100644 
> gcc/testsuite/rust/compile/torture/isolated_cr_block_comment.rs
>  create mode 100644 
> gcc/testsuite/rust/compile/torture/isolated_cr_line_comment.rs
>
Thanks Mark that worked its up now:
https://github.com/Rust-GCC/gccrs/pull/561

Great work once again. I am aiming to spend some time towards the end of
the week to add more tickets and info for new contributors to get
involved, which I will post the interesting ones onto the mailing list
as well. I think it should be interesting to contributors of all levels.
The main one that sticks out in my mind is the AST, HIR dumps which are
a bit of a mess at the moment.

Thanks

--Phil




OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: New contributor tasks

[Philip Herron]

On 12/07/2021 23:44, Mark Wielaard wrote:
> On Mon, Jul 12, 2021 at 11:06:01AM +0100, Philip Herron wrote:
>> Great work once again. I am aiming to spend some time towards the end of
>> the week to add more tickets and info for new contributors to get
>> involved, which I will post the interesting ones onto the mailing list
>> as well. I think it should be interesting to contributors of all levels.
>> The main one that sticks out in my mind is the AST, HIR dumps which are
>> a bit of a mess at the moment.
> The AST dump (--rust-dump-parse) was actually useful for checking the
> comment doc strings, but it could certainly be improved. Ideally it
> would be structured in a way that can easily be used in tests.
I think a really good project would be to update our HIR dump, it should
really be an S-expression format so we can emit the
Analysis::NodeMapping information in a way that looks good at the moment
its a mess.
> Some (random) notes I made on issues that might be nice to explain
> and/or work on.
>
> - Full unicode/utf8 support in the lexer. Currently the lexer only
>   explicitly interprets the input as UTF8 for string parseing. It
>   should really treat all input as UTF-8. gnulib has some handy
>   modules we could use to read/convert from/to utf8 (unistr/u8-to-u32,
>   unistr/u32-to-u8) and test various unicode properties
>   (unictype/property-white-space, unictype/property-xid-continue,
>   unictype/property-xid-start). I don't know if we can import those or
>   if gcc already has these kind of UTF-8/unicode support functions for
>   other languages?
GCCGO supports utf-8 formats for identifiers but I think it has its own
implementation to do this. I think pulling in gnulib sounds like a good
idea, i assume we should ask about this on the GCC mailing list but I
would prefer to reuse a library for utf8 support. The piece about
creating the strings in GENERIC will need updated as part of that work.
> - Error handling using rich locations in the lexer and parser.  It
>   seems some support is already there, but it isn't totally clear to
>   me what is already in place and what could/should be added. e.g. how
>   to add notes to an Error.
I've made a wrapper over RichLocation i had some crashes when i added
methods for annotations. Overall my understanding is that a Location
that we have at the moment is a single character location in the source
code but Rustc uses Spans which might be an abstraction we could think
about implementing instead of the Location wrapper we are reusing for
GCCGO.
> - I noticed some expressions didn't parse because of what looks to me
>   operator precedence issues. e.g the following:
>
>   const S: usize = 64;
>
>   pub fn main ()
>   {
> let a:u8 = 1;
> let b:u8 = 2;
> let _c = S * a as usize + b as usize;
>   }
>
>   $ gcc/gccrs -Bgcc as.rs
>
>   as.rs:7:27: error: type param bounds (in TraitObjectType) are not allowed 
> as TypeNoBounds
> 7 |   let _c = S * a as usize + b as usize;
>   |   ^
>
>   How does one fix such operator precedence issues in the parser?

Off the top of my head it looks as though the parse_type_cast_expr has a
FIXME for the precedence issue for it. The Pratt parser uses the notion
of binding powers to handle this and i think it needs to follow in a
similar style to the ::parse_expr piece.

> - Related, TypeCastExpr as the above aren't lowered from AST to HIR.
>   I believe I know how to do it, but a small description of the visitor
>   pattern used and in which files one does such lowering would be helpful.
The AST->HIR lowering does need some documentation, since it must go
through name-resolution first but there is no documentation on how any
of this works yet. I will put this on my todo list its come up a few
times the naming of some of the classes like ResolveItemToplevel vs
ResolveItem are confusing things. Some of this will get cleaned up as
part of traits, such as the forward declared items within a block bug:

Basically the idea is that we always perform a toplevel scan for all
items and create long canonical names in the top most scope, such that
we can resolve their names at any point without requiring prototypes or
look ahead. This means we have a pass to look for the names then we have
a pass to then resolve each structures fields, functions parameters,
returns types and blocks of code. So if a block calls to a function
declared ahead we can still resolve it to its NodeId. It is when we
ResolveItem we push new contexts onto the stack to have lexical scoping
for names. Its worth noting that Rust also supports shadowing of
variables within a block so these do not cause a duplicate name error
and simply add a new declaration to that context or what rustc calls
Ribs such that further resolution will referenc

Re: [PATCH 2/2] WIP union hir-lowering and type support

[Philip Herron]

On 23/07/2021 00:19, Mark Wielaard wrote:
> Treat a union as a Struct variant like a tuple struct.  Add an
> iterator and get_identifier functions to the AST Union class.  Same
> for the HIR Union class, plus a get_generics_params method. Add a
> get_is_union method tot the ADTType.
> ---
>  gcc/rust/ast/rust-item.h  | 11 
>  gcc/rust/hir/rust-ast-lower-item.h| 51 +
>  gcc/rust/hir/rust-ast-lower-stmt.h| 53 ++
>  gcc/rust/hir/tree/rust-hir-item.h | 16 ++
>  gcc/rust/resolve/rust-ast-resolve-item.h  | 22 
>  gcc/rust/resolve/rust-ast-resolve-stmt.h  | 32 +++
>  gcc/rust/resolve/rust-ast-resolve-toplevel.h  | 14 +
>  gcc/rust/typecheck/rust-hir-type-check-stmt.h | 55 ++-
>  .../typecheck/rust-hir-type-check-toplevel.h  | 54 +-
>  gcc/rust/typecheck/rust-hir-type-check.cc | 12 +++-
>  gcc/rust/typecheck/rust-tycheck-dump.h|  6 ++
>  gcc/rust/typecheck/rust-tyty.cc   |  4 +-
>  gcc/rust/typecheck/rust-tyty.h| 12 ++--
>  13 files changed, 331 insertions(+), 11 deletions(-)
>
> diff --git a/gcc/rust/ast/rust-item.h b/gcc/rust/ast/rust-item.h
> index 30cab0ed900..1e928e8111a 100644
> --- a/gcc/rust/ast/rust-item.h
> +++ b/gcc/rust/ast/rust-item.h
> @@ -2489,6 +2489,15 @@ public:
>std::vector &get_variants () { return variants; }
>const std::vector &get_variants () const { return variants; }
>  
> +  void iterate (std::function cb)
> +  {
> +for (auto &variant : variants)
> +  {
> + if (!cb (variant))
> +   return;
> +  }
> +  }
> +
>std::vector > &get_generic_params ()
>{
>  return generic_params;
> @@ -2505,6 +2514,8 @@ public:
>  return where_clause;
>}
>  
> +  Identifier get_identifier () const { return union_name; }
> +
>  protected:
>/* Use covariance to implement clone function as returning this object
> * rather than base */
> diff --git a/gcc/rust/hir/rust-ast-lower-item.h 
> b/gcc/rust/hir/rust-ast-lower-item.h
> index 5ba59183179..b6af00f6b54 100644
> --- a/gcc/rust/hir/rust-ast-lower-item.h
> +++ b/gcc/rust/hir/rust-ast-lower-item.h
> @@ -192,6 +192,57 @@ public:
>  struct_decl.get_locus ());
>}
>  
> +  void visit (AST::Union &union_decl) override
> +  {
> +std::vector > generic_params;
> +if (union_decl.has_generics ())
> +  {
> + generic_params
> +   = lower_generic_params (union_decl.get_generic_params ());
> +  }
> +
> +std::vector > where_clause_items;
> +HIR::WhereClause where_clause (std::move (where_clause_items));
> +HIR::Visibility vis = HIR::Visibility::create_public ();
> +
> +std::vector variants;
> +union_decl.iterate ([&] (AST::StructField &variant) mutable -> bool {
> +  HIR::Visibility vis = HIR::Visibility::create_public ();
> +  HIR::Type *type
> + = ASTLoweringType::translate (variant.get_field_type ().get ());
> +
> +  auto crate_num = mappings->get_current_crate ();
> +  Analysis::NodeMapping mapping (crate_num, variant.get_node_id (),
> +  mappings->get_next_hir_id (crate_num),
> +  mappings->get_next_localdef_id (
> +crate_num));
> +
> +  HIR::StructField translated_variant (mapping, variant.get_field_name 
> (),
> +std::unique_ptr (type),
> +vis, variant.get_locus (),
> +variant.get_outer_attrs ());
> +  variants.push_back (std::move (translated_variant));
> +  return true;
> +});
> +
> +auto crate_num = mappings->get_current_crate ();
> +Analysis::NodeMapping mapping (crate_num, union_decl.get_node_id (),
> +mappings->get_next_hir_id (crate_num),
> +mappings->get_next_localdef_id (crate_num));
> +
> +translated
> +  = new HIR::Union (mapping, union_decl.get_identifier (), vis,
> + std::move (generic_params), std::move (where_clause),
> + std::move (variants), union_decl.get_outer_attrs (),
> + union_decl.get_locus ());
> +
> +mappings->insert_defid_mapping (mapping.get_defid (), translated);
> +mappings->insert_hir_item (mapping.get_crate_num (), mapping.get_hirid 
> (),
> +translated);
> +mappings->insert_location (crate_num, mapping.get_hirid (),
> +union_decl.get_locus ());
> +  }
> +
>void visit (AST::StaticItem &var) override
>{
>  HIR::Visibility vis = HIR::Visibility::create_public ();
> diff --git a/gcc/rust/hir/rust-ast-lower-stmt.h 
> b/gcc/rust/hir/rust-ast-lower-stmt.h
> index 9df6b746bb7..2e97ca63a13 100644
> --- a/gcc/rust/hir/rust-ast-lower-stmt.h
> +++ b/gcc/rust/hir/rus

Re: [PATCH 1/2] Better union support in the parser

[Philip Herron]

On 23/07/2021 00:19, Mark Wielaard wrote:
> union is a weak keyword which means it isn't reserved and can be used
> as a generic identifier. When we see an identifier where a union could
> be declared we check whether the identifier is "union", but only when
> the next token is also an identifier. In parse_union we shouldn't skip
> the first identifier token, because it is already skipped when we call
> expect_token.
> ---
>  gcc/rust/parse/rust-parse-impl.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/gcc/rust/parse/rust-parse-impl.h 
> b/gcc/rust/parse/rust-parse-impl.h
> index bdf1e09a029..3996ef21672 100644
> --- a/gcc/rust/parse/rust-parse-impl.h
> +++ b/gcc/rust/parse/rust-parse-impl.h
> @@ -1083,7 +1083,8 @@ Parser::parse_item (bool 
> called_from_statement)
>  // crappy hack to do union "keyword"
>  case IDENTIFIER:
>// TODO: ensure std::string and literal comparison works
> -  if (t->get_str () == "union")
> +  if (t->get_str () == "union"
> +   && lexer.peek_token (1)->get_id () == IDENTIFIER)
>   {
> return parse_vis_item (std::move (outer_attrs));
> // or should this go straight to parsing union?
> @@ -1274,8 +1275,8 @@ Parser::parse_vis_item 
> (AST::AttrVec outer_attrs)
>  // TODO: implement union keyword but not really because of
>  // context-dependence case UNION: crappy hack to do union "keyword"
>  case IDENTIFIER:
> -  // TODO: ensure std::string and literal comparison works
> -  if (t->get_str () == "union")
> +  if (t->get_str () == "union"
> +   && lexer.peek_token (1)->get_id () == IDENTIFIER)
>   {
> return parse_union (std::move (vis), std::move (outer_attrs));
> // or should item switch go straight to parsing union?
> @@ -4524,7 +4525,6 @@ Parser::parse_union 
> (AST::Visibility vis,
>const_TokenPtr union_keyword = expect_token (IDENTIFIER);
>rust_assert (union_keyword->get_str () == "union");
>Location locus = union_keyword->get_locus ();
> -  lexer.skip_token ();
>  
>// parse actual union name
>const_TokenPtr union_name_tok = expect_token (IDENTIFIER);
> @@ -6054,8 +6054,8 @@ Parser::parse_stmt ()
>break;
>  // crappy hack to do union "keyword"
>  case IDENTIFIER:
> -  // TODO: ensure std::string and literal comparison works
> -  if (t->get_str () == "union")
> +  if (t->get_str () == "union"
> +   && lexer.peek_token (1)->get_id () == IDENTIFIER)
>   {
> return parse_vis_item (std::move (outer_attrs));
> // or should this go straight to parsing union?
> @@ -11674,8 +11674,8 @@ 
> Parser::parse_stmt_or_expr_without_block ()
>}
>  // crappy hack to do union "keyword"
>  case IDENTIFIER:
> -  // TODO: ensure std::string and literal comparison works
> -  if (t->get_str () == "union")
> +  if (t->get_str () == "union"
> +   && lexer.peek_token (1)->get_id () == IDENTIFIER)
>   {
> std::unique_ptr item (
>   parse_vis_item (std::move (outer_attrs)));

Looks great, I will merge this now.

--Phil




OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Using unsafe blocks in let expressions

[Philip Herron]

On 22/07/2021 00:09, Mark Wielaard wrote:
> On Wed, Jul 21, 2021 at 11:09:38PM +0200, Mark Wielaard wrote:
>> +  Location locus;
>> +  if (!pratt_parse)
>> +{
>> +  Location locus = lexer.peek_token ()->get_locus ();
> Oops, shadowed locus.  Fixed patch attached, and also at
> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=let-unsafe
>
>
>
This was merged yesterday https://github.com/Rust-GCC/gccrs/pull/582

I also merged a simple test case to show the parser is working
https://github.com/Rust-GCC/gccrs/pull/587

The final PR relating to this was:
https://github.com/Rust-GCC/gccrs/pull/589 in the type checker assumed
all dereference expressions were going to be for ReferenceTypes but this
extended it to support pointers. Some work is needed to ensure
derferences and union access outside of match expressions will emit an
error but this is a fairly simple change to make I will update a guide
on how to do this later.

Thanks again

--Phil




OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: rust frontend and UTF-8/unicode processing/properties

[Philip Herron]

On 18/07/2021 23:23, Jason Merrill via Gcc-rust wrote:
> On Sun, Jul 18, 2021 at 1:13 PM Ian Lance Taylor via Gcc
> mailto:g...@gcc.gnu.org>> wrote:
>
> On Sun, Jul 18, 2021 at 6:23 AM Mark Wielaard  > wrote:
> >
> > For the gcc rust frontend I was thinking of importing a couple of
> > gnulib modules to help with UTF-8 processing, conversion to/from
> > unicode codepoints and determining various properties of those
> > codepoints. But it seems gcc doesn't yet have any gnulib modules
> > imported, and maybe other frontends already have helpers to this
> that
> > the gcc rust frontend could reuse.
> >
> > Rust only accepts valid UTF-8 encoded source files, which may or may
> > not start with UTF-8 BOM character. Whitespace is any codepoint with
> > the Pattern_White_Space property. Identifiers can start with any
> > codepoint with the XID_start property plus zero or one
> codepoints with
> > XID_continue property. It isn't required, but highly desirable to
> > detect confusable identifiers according to
> tr39/Confusable_Detection.
> >
> > Other names might be constraint to Alphabetic and/or Number
> categories
> > (Nd, Nl, No), textual types can only contain Unicode Scalar Values
> > (any Unicode codepoint except high-surrogate and low-surrogates),
> > strings in source code can contain unicode escapes (24 bit, up to 6
> > digits codepoints) but are internally stored as UTF-8 (and must not
> > encode any surrogates).
> >
> > Do other gcc frontends handle any of the above already in a way that
> > might be reusable for other frontends?
>
> I don't know that this is particularly helpful, but the Go frontend
> has this kind of code in gcc/go/gofrontend/lex.cc.  E.g.,
> Lex::fetch_char, Lex::advance_one_utf8_char, unicode_space,
> unicode_digits, unicode_letters, Lex::is_unicode_space, etc.  But you
> probably won't be able to use the code directly, and the code in the
> gofrontend directory is also shared with GoLLVM so it can't trivially
> be moved.
>
>
> I believe the UTF-8 handling for the C family front ends is all in
> libcpp; I don't think it's factored in a way to be useful to other
> front ends.
>
> Jason
>
I think it would be ideal to reuse code if possible, it seems like this
project could be an opportunity to at try and make patches to try and
reuse code from other parts of GCC. I bootstrapped the front-end code
from gccgo, which has really helped the project to get going, I would
like to try and give back where I can.

Thanks

--Phil



OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Buildbot failure in Wildebeest Builder on whole buildset

[Philip Herron]

On 04/08/2021 21:25, Mark Wielaard wrote:
> Hi,
>
> On Wed, Aug 04, 2021 at 03:15:00PM +, build...@builder.wildebeest.org 
> wrote:
>> The Buildbot has detected a new failure on builder gccrust-debian-arm64 
>> while building gccrust.
>> Full details are available at:
>> https://builder.wildebeest.org/buildbot/#builders/58/builds/270
>>
>> Buildbot URL: https://builder.wildebeest.org/buildbot/
>>
>> Worker for this Build: debian-arm64
>>
>> Build Reason: 
>> Blamelist: CohenArthur 
>>
>> BUILD FAILED: failed compile (failure)
> This commit (and the following 3) were really bad. They didn't build.
> Apparently bors doesn't check commit individually, but the buildbot
> does build every commit separately.
>
> The tree is buildable again, but I think it would be good to not have
> any commits that break the build.
>
> Periodically broken trees make it also hard to bisect issues.
>
> Is it possible to make bors check all commits in a series? Or can we
> somehow connect the buildbot workers to the bors checks?
>
> Thanks,
>
> Mark
>
Hi Mark,

I think the build-bot checks for every commit is a really nice feature
here. I think you should keep the build-bots as are. I really like to
make sure each of my commits are build-able and pass tests. It keeps me
honest to avoid regressions as best I can.

What do you think?

Thanks

--Phil



OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Modifying self

[Philip Herron]

On 05/08/2021 00:58, Mark Wielaard wrote:
> Hi,
>
> I am trying to get this program working:
>
> extern "C" { fn abort (); }
>
> pub struct H
> {
>   l: u32,
> }
>
> impl H
> {
>   fn p (&mut self) -> u32
>   {
> self.l -= 1;
> self.l
>   }
> }
>
> fn main ()
> {
>   let mut h = H { l: 11 }; 
>   let eleven = h.l; 
>   let ten = h.p (); 
>   if ten + 1 != eleven { unsafe { abort (); } } 
>   let h2 = H { l: ten }; 
>   if h.l != h2.l { unsafe { abort (); } } 
> }
>
> This doesn't currently compile:
>
> $ gcc/gccrs -Bgcc -g p.rs 
> p.rs:12:5: error: invalid left-hand side of assignment
>12 | self.l -= 1;
>   | ^
>
> But this isn't too hard to solve:
>
> diff --git a/gcc/rust/resolve/rust-ast-verify-assignee.h 
> b/gcc/rust/resolve/rust-ast-verify-assignee.h
> index aed01196f81..1e8988d47df 100644
> --- a/gcc/rust/resolve/rust-ast-verify-assignee.h
> +++ b/gcc/rust/resolve/rust-ast-verify-assignee.h
> @@ -75,6 +75,13 @@ public:
>}
>}
>  
> +  void visit (AST::PathInExpression &path) override
> +  {
> +/* XXX do we need to check self is mutable? How?  */
> +if (path.as_string () == "self")
> +  ok = true;
> +  }
> +
>  private:
>VerifyAsignee (NodeId parent) : ResolverBase (parent), ok (false) {}
>  
> I am not sure whether this is a good implementation of the
> VerifyAsignee visitor for a PathInExpression. What exactly is the goal
> of this visitor?
>
> But with the above simple fix, it compiles! And it actually seems to
> mostly work. The implementation method is called, it gets its own
> field, substracts the value and correctly returns it!
>
> But... then it still aborts on the second check.  The method was
> supposed to adjust the given self (H), but it is not given a mutable
> reference, it gets a copy...
>
> On irc Philip suggested this is probably
> https://github.com/Rust-GCC/gccrs/issues/241
>
> But I must admit I don't fully understand what really needs to be done
> here or if the fact that this is a &mut self makes it different from a
> &self argument.
>
> Cheers,
>
> Mark
>
This is a fantastic test case. I think we should add this to the xfail
section. In terms of getting the mutable self working on methods, its a
little more complex since the compiler is very permissive here, where
the type system is meant to be able to coerce the reciever with a system
called autoderef which is not documented very well. This is something
that must be fixed as part of traits since you can end up with many
candidates for a path or method call and choosing the correct one is
very important to get right.

This missing feature is causing a deficiency in constant folding from
this issue: https://github.com/Rust-GCC/gccrs/issues/547

The verify lvalue looks good, this validation could really do with some
work down the line. I will reply to this thread when some movement is
made here on this.

--Phil




OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH] More rustspec.cc cleanups

[Philip Herron]

On 06/08/2021 00:34, Mark Wielaard wrote:
> rustspec.cc was based on the Go frontend gospec.cc. Remove special
> handling of math and pthread libraries and profiling option. Handle
> .rs files instead of .go files. Keep support for linking with (static)
> librust which is currently commented out. Add generic static-librust
> option to common.opt.
> ---
>  gcc/common.opt  |   4 ++
>  gcc/rust/config-lang.in |   2 +-
>  gcc/rust/rustspec.cc| 146 
>  3 files changed, 32 insertions(+), 120 deletions(-)
>
> diff --git a/gcc/common.opt b/gcc/common.opt
> index c75dd36843e..820de1f41b0 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -3449,6 +3449,10 @@ static-libgo
>  Driver
>  ; Documented for Go, but always accepted by driver.
>  
> +static-librust
> +Driver
> +; Documented for Rust, but always accepted by driver.
> +
>  static-libasan
>  Driver
>  
> diff --git a/gcc/rust/config-lang.in b/gcc/rust/config-lang.in
> index c50b72153c2..1d61d2afc6b 100644
> --- a/gcc/rust/config-lang.in
> +++ b/gcc/rust/config-lang.in
> @@ -1,4 +1,4 @@
> -# config-lang.in -- Top level configure fragment for gcc Go frontend.
> +# config-lang.in -- Top level configure fragment for gcc Rust frontend.
>  
>  # Copyright (C) 2009-2019 Free Software Foundation, Inc.
>  
> diff --git a/gcc/rust/rustspec.cc b/gcc/rust/rustspec.cc
> index 12ec874d222..806514a9d94 100644
> --- a/gcc/rust/rustspec.cc
> +++ b/gcc/rust/rustspec.cc
> @@ -1,4 +1,4 @@
> -/* rustspec.c -- Specific flags and argument handling of the gcc Go front 
> end.
> +/* rustspec.c -- Specific flags and argument handling of the gcc Rust front 
> end.
> Copyright (C) 2009-2020 Free Software Foundation, Inc.
>  
>  This file is part of GCC.
> @@ -28,24 +28,10 @@ along with GCC; see the file COPYING3.  If not see
>  
>  /* This bit is set if we saw a `-xfoo' language specification.  */
>  #define LANGSPEC (1 << 1)
> -/* This bit is set if they did `-lm' or `-lmath'.  */
> -#define MATHLIB (1 << 2)
> -/* This bit is set if they did `-lpthread'.  */
> -#define THREADLIB (1 << 3)
>  /* This bit is set if they did `-lc'.  */
> -#define WITHLIBC (1 << 4)
> +#define WITHLIBC (1 << 2)
>  /* Skip this option.  */
> -#define SKIPOPT (1 << 5)
> -
> -#ifndef MATH_LIBRARY
> -#define MATH_LIBRARY "m"
> -#endif
> -#ifndef MATH_LIBRARY_PROFILE
> -#define MATH_LIBRARY_PROFILE MATH_LIBRARY
> -#endif
> -
> -#define THREAD_LIBRARY "pthread"
> -#define THREAD_LIBRARY_PROFILE THREAD_LIBRARY
> +#define SKIPOPT (1 << 3)
>  
>  void
>  lang_specific_driver (struct cl_decoded_option **in_decoded_options,
> @@ -54,38 +40,23 @@ lang_specific_driver (struct cl_decoded_option 
> **in_decoded_options,
>  {
>unsigned int i, j;
>  
> -  /* If true, the user gave us the `-p' or `-pg' flag.  */
> -  bool saw_profile_flag = false;
> -
>/* This is a tristate:
> - -1 means we should not link in libgo
> - 0  means we should link in libgo if it is needed
> - 1  means libgo is needed and should be linked in.
> - 2  means libgo is needed and should be linked statically.  */
> + -1 means we should not link in librust
> + 0  means we should link in librust if it is needed
> + 1  means librust is needed and should be linked in.
> + 2  means librust is needed and should be linked statically.  */
>int library = 0;
>  
>/* The new argument list will be contained in this.  */
>struct cl_decoded_option *new_decoded_options;
>  
> -  /* "-lm" or "-lmath" if it appears on the command line.  */
> -  const struct cl_decoded_option *saw_math = 0;
> -
> -  /* "-lpthread" if it appears on the command line.  */
> -  const struct cl_decoded_option *saw_thread = 0;
> -
>/* "-lc" if it appears on the command line.  */
>const struct cl_decoded_option *saw_libc = 0;
>  
>/* An array used to flag each argument that needs a bit set for
> - LANGSPEC, MATHLIB, or WITHLIBC.  */
> + LANGSPEC or WITHLIBC.  */
>int *args;
>  
> -  /* Whether we need the thread library.  */
> -  int need_thread = 0;
> -
> -  /* By default, we throw on the math library if we have one.  */
> -  int need_math = (MATH_LIBRARY[0] != '\0');
> -
>/* True if we saw -static.  */
>int static_link = 0;
>  
> @@ -115,8 +86,8 @@ lang_specific_driver (struct cl_decoded_option 
> **in_decoded_options,
>/* Whether the -S option was used.  */
>bool saw_opt_S = false;
>  
> -  /* The first input file with an extension of .go.  */
> -  const char *first_go_file = NULL;
> +  /* The first input file with an extension of .rs.  */
> +  const char *first_rust_file = NULL;
>  
>argc = *in_decoded_options_count;
>decoded_options = *in_decoded_options;
> @@ -137,34 +108,22 @@ lang_specific_driver (struct cl_decoded_option 
> **in_decoded_options,
> break;
>  
>   case OPT_l:
> -   if (strcmp (arg, MATH_LIBRARY) == 0)
> - {
> -   args[i] |= MATHLIB;
> -   need_math = 0;
> - }
> -

Re: [PATCH] Pass pratt parsed token to expr parser functions to fix expr locus

[Philip Herron]

On 05/08/2021 20:37, Mark Wielaard wrote:
> Hi,
>
> On Fri, Jul 30, 2021 at 03:03:13AM +0200, Mark Wielaard wrote:
>> That variant is attached and can also be found here:
>> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=pass-pratt-parse-loc
>> The original is also here:
>> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=pass-pratt-parse-token
>>
>> Hopefully one of the two is acceptable. If not please let me know how
>> to rewrite it in a cheaper more idiomatic way.
> Any feedback on these patches? I really like to get the locations
> correct for these pratt parsed expressions. If both variants are
> problematic please let me know what I can do to improve them.
>
> Thanks,
>
> Mark
>
Hi Mark,

Sorry for lack of reply on this. After looking into this and also
getting Arthur Cohen to review, I think:

  * Token passing: If we end up using the token for more than the
location this might be useful but at present I can't think of a
use-case for the token. If we do need it maybe we could look into
passing it by reference.
  * Location passing: I think this is the best solution and is directly
associated with the issue you have fixed. The function says that you
can call me but tell me the location as well so its up to the caller
to handle this. We should add a comment to the function prototypes
to say what the location is but that's it.

What do you think?

Thanks

--Phil



OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH] More rustspec.cc cleanups

[Philip Herron]

On 07/08/2021 00:08, Mark Wielaard wrote:
> Hi Philip,
>
> On Fri, Aug 06, 2021 at 03:58:24PM +0100, Philip Herron wrote:
>> Great patch, this file has been neglected. This is now being merged
>> https://github.com/Rust-GCC/gccrs/pull/610
>>
>> Its not 100% clear but is the compiler driver here automatically adding
>> in -lc or is it simply checking if it saw_libc?
> It does pass -lc (if not saw_libc).  You can see what is invoked with
> which arguments using -v (e.g. gcc/gccrs -B gcc -v foobar.rs).
>
> One of the things we are using is the crt1.o startup code, which
> provides the _start symbol and which relies on libc (in particular
> __libc_start_main and abort).
>
> The patch wasn't really meant to change how we currently do
> assembling, linking and startup. But just to remove those parts that
> were unnecessary because they were go specific.
>
> Cheers,
>
> Mark
>
Awesome thanks for checking. Agreed that this patch was not meant to
change that behavior but it was a great start at cleaning up the driver.

I am now wondering if rustc reuses the same type of startup code. I'll
go ask more questions about it :)

Thanks

--Phil 




OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Buildbot failure in Wildebeest Builder on whole buildset

[Philip Herron]

On 06/08/2021 23:39, Mark Wielaard wrote:
> Hi Philip,
>
> On Fri, Aug 06, 2021 at 03:31:07PM +0100, Philip Herron wrote:
>>> Is it possible to make bors check all commits in a series? Or can we
>>> somehow connect the buildbot workers to the bors checks?
>> I think the build-bot checks for every commit is a really nice feature
>> here. I think you should keep the build-bots as are. I really like to
>> make sure each of my commits are build-able and pass tests. It keeps me
>> honest to avoid regressions as best I can.
>>
>> What do you think?
> I am just a little afraid it is running too late. But I am pretty
> happy we have workers for 4 different architectures and they are green
> most of the time. We really should add a 32bit (i686 or armhf) one
> just to be sure that works correctly.
>
> Currently i686 gets lots of failures like:
>
> /home/mark/gccrs/gcc/testsuite/rust/compile/torture/methods3.rs:27:5: error: 
> type mismatch in binary exp
> ression
> f64
> 
> 
> D.229 = _2 + _4;
> /home/mark/gccrs/gcc/testsuite/rust/compile/torture/methods3.rs:27:5: 
> internal compiler error: 'verify_g
> imple' failed
> 0x8b41fd4 verify_gimple_in_seq(gimple*)
> ../../gccrs/gcc/tree-cfg.c:5157
> 0x884b4c3 gimplify_body(tree_node*, bool)
> ../../gccrs/gcc/gimplify.c:15401
> 0x884b692 gimplify_function_tree(tree_node*)
> ../../gccrs/gcc/gimplify.c:15472
> 0x86a6448 cgraph_node::analyze()
> ../../gccrs/gcc/cgraphunit.c:670
> 0x86a9218 analyze_functions
> ../../gccrs/gcc/cgraphunit.c:1236
> 0x86a9e01 symbol_table::finalize_compilation_unit()
> ../../gccrs/gcc/cgraphunit.c:2514
>
> Cheers,
>
> Mark
>
I would be interested in seeing 32bit build bots since this patch has
been merged: https://github.com/Rust-GCC/gccrs/pull/614

Which thanks to Adrian who has been testing it out.

Do you have access to 32bit machines? I have some unused space on
digital ocean where we could put some build-bots if you like?

Thanks

--Phil




OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Buildbot failure in Wildebeest Builder on whole buildset

[Philip Herron]

On 06/08/2021 16:55, cohenarthur.dev wrote:
> On 21/08/06 03:31PM, Philip Herron wrote:
>> On 04/08/2021 21:25, Mark Wielaard wrote:
>>> Hi,
>>>
>>> On Wed, Aug 04, 2021 at 03:15:00PM +, build...@builder.wildebeest.org 
>>> wrote:
>>>> The Buildbot has detected a new failure on builder gccrust-debian-arm64 
>>>> while building gccrust.
>>>> Full details are available at:
>>>> https://builder.wildebeest.org/buildbot/#builders/58/builds/270
>>>>
>>>> Buildbot URL: https://builder.wildebeest.org/buildbot/
>>>>
>>>> Worker for this Build: debian-arm64
>>>>
>>>> Build Reason: 
>>>> Blamelist: CohenArthur 
>>>>
>>>> BUILD FAILED: failed compile (failure)
>>> This commit (and the following 3) were really bad. They didn't build.
>>> Apparently bors doesn't check commit individually, but the buildbot
>>> does build every commit separately.
> Really sorry about this.
>
>>> The tree is buildable again, but I think it would be good to not have
>>> any commits that break the build.
>>>
>>> Periodically broken trees make it also hard to bisect issues.
>>>
>>> Is it possible to make bors check all commits in a series? Or can we
>>> somehow connect the buildbot workers to the bors checks?
> I think bors is mostly focused on having the latest commit on the main
> branch always build, but I might be wrong on this. I think it should be
> possible to integrate buildbot to the CI on github directly, side to
> side with bors.
>
>>> Thanks,
>>>
>>> Mark
>>>
>> Hi Mark,
>>
>> I think the build-bot checks for every commit is a really nice feature
>> here. I think you should keep the build-bots as are. I really like to
>> make sure each of my commits are build-able and pass tests. It keeps me
>> honest to avoid regressions as best I can.
>>
>> What do you think?
>>
>> Thanks
>>
>> --Phil
>>
> I'm really sorry about not having all the commits build. I tried to keep
> them as atomic as possible and clearly didn't check all of them
> separately. This could have been a single commit and would have avoided
> this, but since each change was big I decided to split them up.
>
> I was not aware that buildbot checks every commit separately. I think
> this is a good feature, and I'll keep it in mind. Won't happen again!
>
> Sorry again,
>
> --
> Arthur

No need to apologies Arthur, you've done great work! This is something
we haven't thought about before until now.

Thanks

--Phil




OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH] Pass pratt parsed token to expr parser functions to fix expr locus

[Philip Herron]

On 07/08/2021 02:01, Mark Wielaard wrote:
> On Fri, Aug 06, 2021 at 04:23:27PM +0100, Philip Herron wrote:
>> On 05/08/2021 20:37, Mark Wielaard wrote:
>>> Hi,
>>>
>>> On Fri, Jul 30, 2021 at 03:03:13AM +0200, Mark Wielaard wrote:
>>>> That variant is attached and can also be found here:
>>>> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=pass-pratt-parse-loc
>>>> The original is also here:
>>>> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=pass-pratt-parse-token
>>>>
>>>> Hopefully one of the two is acceptable. If not please let me know how
>>>> to rewrite it in a cheaper more idiomatic way.
>>> Any feedback on these patches? I really like to get the locations
>>> correct for these pratt parsed expressions. If both variants are
>>> problematic please let me know what I can do to improve them.
>>>
>>> Thanks,
>>>
>>> Mark
>>>
>> Hi Mark,
>>
>> Sorry for lack of reply on this. After looking into this and also
>> getting Arthur Cohen to review, I think:
>>
>>   * Token passing: If we end up using the token for more than the
>> location this might be useful but at present I can't think of a
>> use-case for the token. If we do need it maybe we could look into
>> passing it by reference.
>>   * Location passing: I think this is the best solution and is directly
>> associated with the issue you have fixed. The function says that you
>> can call me but tell me the location as well so its up to the caller
>> to handle this. We should add a comment to the function prototypes
>> to say what the location is but that's it.
>>
>> What do you think?
> OK, lets go with the location passing. I added a comment to the
> function prototypes in rust-parse.h about the passed in
> pratt_parsed_token.
>
> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=pass-pratt-parse-token
>
> Cheers,
>
> Mark

Thanks Mark, I will merge this one.

--Phil




OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH] lex: accept zero codepoints in strings

[Philip Herron]

On 07/08/2021 16:45, Mark Wielaard wrote:
> Zero characters (codepoints) are acceptable in strings. The current
> Lexer::parse_string skipped such zero codepoints by accidents. The
> zero codepoint was also used as error/skip indicator, but that is only
> true if the third argument of utf8_escape_pair is true (yes, it is
> called pair, but is a triple).
>
> Add a testcase that checks the (sub)strings are separated by zero
> chars. Since we cannot slice strings yet this uses extern "C"
> functions, printf and memchr.
> ---
>
> On irc bjorn3_gh pointed out that our lexer ate embedded zero chars
> from strings. This fixes that issue and adds a testcase. Also on
> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=str-zero
>
>  gcc/rust/lex/rust-lex.cc  |  2 +-
>  .../rust/execute/torture/str-zero.rs  | 26 +++
>  2 files changed, 27 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/rust/execute/torture/str-zero.rs
>
> diff --git a/gcc/rust/lex/rust-lex.cc b/gcc/rust/lex/rust-lex.cc
> index 0b8a8eae651..2cfbc4fb1f4 100644
> --- a/gcc/rust/lex/rust-lex.cc
> +++ b/gcc/rust/lex/rust-lex.cc
> @@ -1827,7 +1827,7 @@ Lexer::parse_string (Location loc)
> else
>   length += std::get<1> (utf8_escape_pair);
>  
> -   if (current_char32 != Codepoint (0))
> +   if (current_char32 != Codepoint (0) || !std::get<2> 
> (utf8_escape_pair))
>   str += current_char32;
>  
> // required as parsing utf8 escape only changes current_char
> diff --git a/gcc/testsuite/rust/execute/torture/str-zero.rs 
> b/gcc/testsuite/rust/execute/torture/str-zero.rs
> new file mode 100644
> index 000..e7fba0d1372
> --- /dev/null
> +++ b/gcc/testsuite/rust/execute/torture/str-zero.rs
> @@ -0,0 +1,26 @@
> +/* { dg-output "bar foo baz foobar\n" } */
> +extern "C"
> +{
> +  fn printf(s: *const i8, ...);
> +  fn memchr(s: *const i8, c: u8, n: usize) -> *const i8;
> +}
> +
> +pub fn main () -> i32
> +{
> +  let f = "%s %s %s %s\n\0";
> +  let s = "bar\0\
> +   foo\
> +   \x00\
> +   baz\u{}\
> +   foobar\0";
> +  let cf = f as *const str as *const i8;
> +  let cs = s as *const str as *const i8;
> +  unsafe
> +{
> +  let cs2 = memchr (cs, b'f', 5);
> +  let cs3 = memchr (cs2, b'b', 5);
> +  let cs4 = memchr (cs3, b'f', 5);
> +  printf (cf, cs, cs2, cs3, cs4);
> +}
> +  0
> +}

Hi Mark,

This patch looks good to go but the clang-format check is failing:
https://github.com/Rust-GCC/gccrs/pull/615

The error seems to be that it moves the extra check onto a new line.
https://github.com/Rust-GCC/gccrs/pull/615/checks?check_run_id=3272823975

Thanks

--Phil




OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH] Reject duplicate field names in structs and unions.

[Philip Herron]

Nice work once again, just to let you know about the little bit of
duplication I think the name resolver needs a little bit of thought to
handle forward declared items within a block like this:
https://github.com/Rust-GCC/gccrs/issues/531. It might be as simple as
calling ResolveToplevelItems when doing block expr resolution. Depending on
how we fix this it might feed back a way to avoid this little bit of
duplication.

Thanks

--Phil

On Sun, 22 Aug 2021 at 00:48, Mark Wielaard  wrote:

> Odd things happen if structs or unions have duplicate field names.
> Emit an error when lowering an struct/union item or declaration
> statement and a duplicate field name is detected.  A new testcase
> 'dup_fields.rs' checks an error is actually produced.
> ---
>
> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=dup_fields
>
>  gcc/rust/hir/rust-ast-lower-item.h   | 27 
>  gcc/rust/hir/rust-ast-lower-stmt.h   | 27 
>  gcc/testsuite/rust/compile/dup_fields.rs | 23 
>  3 files changed, 77 insertions(+)
>  create mode 100644 gcc/testsuite/rust/compile/dup_fields.rs
>
> diff --git a/gcc/rust/hir/rust-ast-lower-item.h
> b/gcc/rust/hir/rust-ast-lower-item.h
> index bcf83ee63b6..b324d0b5b8b 100644
> --- a/gcc/rust/hir/rust-ast-lower-item.h
> +++ b/gcc/rust/hir/rust-ast-lower-item.h
> @@ -176,6 +176,25 @@ public:
>struct_decl.get_locus ());
>}
>
> +  /* Checks whether the name of a field already exists.  Returns true
> + and produces an error if so.  */
> +  static bool struct_field_name_exists (std::vector
> &fields,
> +   HIR::StructField &new_field)
> +  {
> +for (auto &field : fields)
> +  {
> +   if (field.get_field_name ().compare (new_field.get_field_name ())
> == 0)
> + {
> +   RichLocation r (new_field.get_locus ());
> +   r.add_range (field.get_locus ());
> +   rust_error_at (r, "duplicate field name %qs",
> +  field.get_field_name ().c_str ());
> +   return true;
> + }
> +  }
> +return false;
> +  }
> +
>void visit (AST::StructStruct &struct_decl) override
>{
>  std::vector > generic_params;
> @@ -206,6 +225,10 @@ public:
>  std::unique_ptr
> (type), vis,
>  field.get_locus (),
>  field.get_outer_attrs ());
> +
> +  if (struct_field_name_exists (fields, translated_field))
> +   return false;
> +
>fields.push_back (std::move (translated_field));
>return true;
>  });
> @@ -258,6 +281,10 @@ public:
>std::unique_ptr
> (type),
>vis, variant.get_locus (),
>variant.get_outer_attrs ());
> +
> +  if (struct_field_name_exists (variants, translated_variant))
> +   return false;
> +
>variants.push_back (std::move (translated_variant));
>return true;
>  });
> diff --git a/gcc/rust/hir/rust-ast-lower-stmt.h
> b/gcc/rust/hir/rust-ast-lower-stmt.h
> index c4c00ac0bee..1e72c8a2023 100644
> --- a/gcc/rust/hir/rust-ast-lower-stmt.h
> +++ b/gcc/rust/hir/rust-ast-lower-stmt.h
> @@ -161,6 +161,25 @@ public:
>struct_decl.get_locus ());
>}
>
> +  /* Checks whether the name of a field already exists.  Returns true
> + and produces an error if so.  */
> +  static bool struct_field_name_exists (std::vector
> &fields,
> +   HIR::StructField &new_field)
> +  {
> +for (auto &field : fields)
> +  {
> +   if (field.get_field_name ().compare (new_field.get_field_name ())
> == 0)
> + {
> +   RichLocation r (new_field.get_locus ());
> +   r.add_range (field.get_locus ());
> +   rust_error_at (r, "duplicate field name %qs",
> +  field.get_field_name ().c_str ());
> +   return true;
> + }
> +  }
> +return false;
> +  }
> +
>void visit (AST::StructStruct &struct_decl) override
>{
>  std::vector > generic_params;
> @@ -191,6 +210,10 @@ public:
>  std::unique_ptr
> (type), vis,
>  field.get_locus (),
>  field.get_outer_attrs ());
> +
> +  if (struct_field_name_exists (fields, translated_field))
> +   return false;
> +
>fields.push_back (std::move (translated_field));
>return true;
>  });
> @@ -242,6 +265,10 @@ public:
>std::unique_ptr
> (type),
>vis, variant.get_locus (),
>variant.get_outer_attrs ());
> +
> +  if (struct_field_name_exists 

GCC Rust community call

[Philip Herron]

Hi everyone,

It's that time again, and we will have our regular monthly call.

   - Date and Time 3rd September 2021 at 1000 (BST, which is UTC+1)
   - Agenda: https://hackmd.io/wflqJlFvS6edEsqf1oo-Hg, please feel free to
   add agenda items you wish to see discussed.
   - Jitsi: https://meet.jit.si/259057065581073

The August monthly report is also available here:
https://github.com/Rust-GCC/Reporting/blob/main/2021-08-monthly-report.org.

Please feel free to join and ask questions or, if you prefer, simply listen
in.

Have a great week. Thanks

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

Re: Cleanup some StructExpr related classes

[Philip Herron]

This is fantastic work Mar. This brings us closer to the AST structures of
rustc and does simplify a lot of the analysis within the compiler.
https://doc.rust-lang.org/nightly/reference/expressions/struct-expr.html

I agree the HIR cleanup will also help reduce a lot of duplication of code
and visitors. It might mean we get alot of enum stuff for free potentially.

Thanks

--Phil


On Wed, 1 Sept 2021 at 01:16, Mark Wielaard  wrote:

> Hi,
>
> There are various Structure Expressions that don't actually "exist"
> because they are syntactically equivalent to other constructs. So we
> never really construct or use these classes. But they are still listed
> in various visitors, which is somewhat confusing. Removing the AST and
> HIR variants of these classes really cleans up the code IMHO.
>
> The following 3 patches can also be found on
> https://code.wildebeest.org/git/user/mjw/gccrs/log/?h=structexpr
>
> [PATCH 1/3] StructExprTuple doesn't really exist
> [PATCH 2/3] StructExprUnit doesn't really exist
> [PATCH 3/3] Remove Enumaration Expression, EnumExpr, classes
>
> Cheers,
>
> Mark
> --
> 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: Cleanup some StructExpr related classes

[Philip Herron]

Hi Mark,

I've been reviewing your branch a bit and noticed this commit
https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=enums&id=84d27b926e09ef44dd94be20c97d72bd4b865c40
which I really like. I wasn't sure what was the best way to interact with
the AST which contained unique_ptr's to things so I initially added little
lambda's but these don't really help anything at all other than make it
more confusing to work with. So feel free to create patches to remove those.

I also noticed quite a few test cases already are these compiling? And did
you have to add much to the rust-gcc.cc wrapper for the enum type?

Thanks,
--Phil

On Wed, 1 Sept 2021 at 20:24, Mark Wielaard  wrote:

> Hi,
>
> On Wed, Sep 01, 2021 at 11:11:46AM +0100, Philip Herron wrote:
> > This is fantastic work Mar. This brings us closer to the AST structures
> of
> > rustc and does simplify a lot of the analysis within the compiler.
> > https://doc.rust-lang.org/nightly/reference/expressions/struct-expr.html
>
> The reference does change from time to time. The older one did
> describe various constructs that the newer does and for some it still
> has comments saying some construct doesn't really construct, like the
> tuple expression, which is simply a call (constructor) expression.  I
> don't know if there is some kind of change log for the Rust reference.
>
> Note that there are some more StructExpr cleanups at:
> https://github.com/Rust-GCC/gccrs/pull/405
> Which might be nice to finish.
>
> > I agree the HIR cleanup will also help reduce a lot of duplication of
> code
> > and visitors. It might mean we get alot of enum stuff for free
> potentially.
>
> Potentially yes, but in practice enum item variants are different
> enough to require lots of new code. I have patches for the parser,
> resolver, and ast-hir-lowering and working on type-checking. One
> tricky issue is that references to an enum item are paths with the
> enum name first and the enum item second (Enum::Item). Which is
> somewhat more complex than the IdentifierExpr. Another is that a
> struct has one constructor, an enum has multiple (depending on the
> enum item variant). So you need to add variants to the ADTType.
>
> Work in progress at
> https://code.wildebeest.org/git/user/mjw/gccrs/log/?h=enums
> cleaned up patches (that I hope are correct) at
> https://code.wildebeest.org/git/user/mjw/gccrs/log/?h=enums2
>
> Cheers,
>
> Mark
>
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: GCC Rust community call

[Philip Herron]

The agenda document has been updated to contain all relevant points I can
think of, but feel free to pose any questions during the meeting.
https://hackmd.io/wflqJlFvS6edEsqf1oo-Hg?view

Thanks

--Phil

On Tue, 31 Aug 2021 at 11:15, Philip Herron 
wrote:

> Hi everyone,
>
> It's that time again, and we will have our regular monthly call.
>
>- Date and Time 3rd September 2021 at 1000 (BST, which is UTC+1)
>- Agenda: https://hackmd.io/wflqJlFvS6edEsqf1oo-Hg, please feel free
>to add agenda items you wish to see discussed.
>- Jitsi: https://meet.jit.si/259057065581073
>
> The August monthly report is also available here:
> https://github.com/Rust-GCC/Reporting/blob/main/2021-08-monthly-report.org
> .
>
> Please feel free to join and ask questions or, if you prefer, simply
> listen in.
>
> Have a great week. Thanks
>
> --Phil
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Rust Compatibility

[Philip Herron]

Hi everyone,

Yesterday this issue was posted to us on GitHub
https://github.com/Rust-GCC/gccrs/issues/653, which revolves around
strict-aliasing rules.

The conversation was focused on what level of compatibility we are aiming
for in the Rust language. This is important, and I don't believe we should
allow specific language features/development outside the official Rust
processes. This means we do not want to have any GCC specific attributes or
language features and we won't provide a shortcut to bypass RFC processes.

Though I believe we should always allow users to invoke GCC Rust however
they wish (since the FE inherits the common GCC options), this is the point
of free software to me. To mitigate any GCC vs Rustc incompatibility, our
cargo-gccrs wrapper was always intended to map rust arguments over to the
GCC version of these to get the intended Rustc behaviour. But still, when
users want to invoke gccrs directly, it is up to them to choose what
options they want, good or bad, including using gcc-plugins.

Some of the feedback seems that if we allow users to compile code with or
without strict aliasing, this may allow for code to compile with GCC but
not with rustc which "splits the ecosystem". So I wanted to run this by you
guys here to get feedback on what people think about allowing users to
choose their GCC compilation options in general.

Thanks

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

Re: Cleanup some StructExpr related classes

[Philip Herron]

Hi Mark,

Well done on the new patches they are currently being merged. I imagine the
typechecking could be a bit more complex since correct me if I am wrong but
I feel like this might end up affecting the whole PathInExpression
resolution which is fairly complicated. There is a nullptr bug there if it
fails to resolve the root segment.

I imagine there might need to be a check in the resolve_segments for if the
tyseg which will be the type of the previous segment, if that is an ADTType
which is an enum then look for the name of the field within the struct but
i am not 100% sure if it does affect the PathInExpression stuff.

Let me know if there is anything I can do to help or review? I don't mind
checking out your branches to play with too.

Thanks

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

Re: [PATCH] Fix byte char and byte string lexing code

[Philip Herron]

Hi guys,

Thanks, Thomas for raising the PR it is currently being merged. We will
raise the next PR to get bootstrapable builds working which will be really
nice there is a GitHub automation for that at the moment.

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?

Thanks again

--Phil

On Wed, 22 Sept 2021 at 21:37, Mark Wielaard  wrote:

> Hi Thomas,
>
> On Wed, Sep 22, 2021 at 11:48:56AM +0200, Thomas Schwinge wrote:
> > That's .
> > [...]
> > That's .
>
> Ah, sorry, I don't really track the github issues and had missed
> those. But good to see the analysis matches.
>
> > Both these related to 
> > "GCC '--enable-bootstrap' build".
>
> To make --enable-bootstrap possible (wow, that takes a long time...)
> you'll also need:
> https://gcc.gnu.org/pipermail/gcc-rust/2021-September/000178.html
>
> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=rust-mangle-unreachable
>
> With this and that patch applied there are no more warnings building
> the rust frontend, so a --enable-bootstrap (-Werror) build completes
> successfully.
>
> > >
> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=bytecharstring
> >
> > Thanks, that's now: 
> > "Fix byte char and byte string lexing code".
>
> Thanks,
>
> Mark
>
> --
> 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: 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: [PATCH] Fix raw byte string parsing of zero and out of range bytes

[Philip Herron]

Hi Mark,

This looks good and it is currently being merged:
https://github.com/Rust-GCC/gccrs/pull/695, I will catch up with your other
patches through the day.

Thanks

--Phil

On Wed, 29 Sept 2021 at 21:35, Mark Wielaard  wrote:

> Allow \0 escape in raw byte string and reject non-ascii byte
> values. Change parse_partial_hex_escapes to not skip bad characters to
> provide better error messages.
>
> Add rawbytestring.rs testcase to check string, raw string, byte string
> and raw byte string parsing.
> ---
>
>
> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=parse-raw-byte-string
>
>  gcc/rust/lex/rust-lex.cc|  20 +++-
>  gcc/testsuite/rust/compile/rawbytestring.rs | Bin 0 -> 3234 bytes
>  2 files changed, 15 insertions(+), 5 deletions(-)
>  create mode 100644 gcc/testsuite/rust/compile/rawbytestring.rs
>
> diff --git a/gcc/rust/lex/rust-lex.cc b/gcc/rust/lex/rust-lex.cc
> index b70877be9ff..bbddea04d0c 100644
> --- a/gcc/rust/lex/rust-lex.cc
> +++ b/gcc/rust/lex/rust-lex.cc
> @@ -1423,8 +1423,7 @@ Lexer::parse_partial_hex_escape ()
>char hexNum[3] = {0, 0, 0};
>
>// first hex char
> -  skip_input ();
> -  current_char = peek_input ();
> +  current_char = peek_input (1);
>int additional_length_offset = 1;
>
>if (!is_x_digit (current_char))
> @@ -1432,20 +1431,23 @@ Lexer::parse_partial_hex_escape ()
>rust_error_at (get_current_location (),
>  "invalid character %<\\x%c%> in \\x sequence",
>  current_char);
> +  return std::make_pair (0, 0);
>  }
>hexNum[0] = current_char;
>
>// second hex char
>skip_input ();
> -  current_char = peek_input ();
> +  current_char = peek_input (1);
>additional_length_offset++;
>
>if (!is_x_digit (current_char))
>  {
>rust_error_at (get_current_location (),
> -"invalid character %<\\x%c%> in \\x sequence",
> +"invalid character %<\\x%c%c%> in \\x sequence",
> hexNum[0],
>  current_char);
> +  return std::make_pair (0, 1);
>  }
> +  skip_input ();
>hexNum[1] = current_char;
>
>long hexLong = std::strtol (hexNum, nullptr, 16);
> @@ -1627,7 +1629,7 @@ Lexer::parse_byte_string (Location loc)
>   else
> length += std::get<1> (escape_length_pair);
>
> - if (output_char != 0)
> + if (output_char != 0 || !std::get<2> (escape_length_pair))
> str += output_char;
>
>   continue;
> @@ -1722,6 +1724,14 @@ Lexer::parse_raw_byte_string (Location loc)
> }
> }
>
> +  if ((unsigned char) current_char > 127)
> +   {
> + rust_error_at (get_current_location (),
> +"character %<%c%> in raw byte string out of
> range",
> +current_char);
> + current_char = 0;
> +   }
> +
>length++;
>
>str += current_char;
> diff --git a/gcc/testsuite/rust/compile/rawbytestring.rs
> b/gcc/testsuite/rust/compile/rawbytestring.rs
> new file mode 100644
> index
> ..9c6b762a7fd378206a3bfe21db5b708890f5466f
> GIT binary patch
> literal 3234
> zcmbVOO>fgc5amjL#mG4T6)1rVl`5`1a^M^Zc^f;m2zI;c($Wfvf5=~A-pqd4PU65Z
> z<9Tmp-n`vS-O~56Y3cQwv*$CS<&wUX59E5=v|Go4UDeZ9>ni$0wkR&M$OnWLi=tR8
> zvhYe0>#n0kp8Z~u3yqU0ZIOclm4066_dMaIdKBLE zC8SmEy1cFEe3@FkZM6EI->90VG(Y=lGOCeT&0tuLp+z$p*Er0}$>V{I!^8|YFtTxx
> z@X*l4>D0{rUt=35bE5|t9J_s{&GuboZD* zc%EYYDlHYkjRXh2@TuH1=aM+;Gqyvv;&mx;T8-!69@lIn-t3a5*&*G8KFpvI38NDZ
> zXRR0;(@$zf^Mz-&9d5I9*G z&}eCgAm&LiE1Ztuo)19+f+2(Qu2!m#_4vb;|G-CZh`7Kh;Epf$lpotHpVZa9RxPJ`
> z*!LJ1N@A_5D-K2!c50h=c|}nH2&&HIi=qJdndb5#r=*{jFDfG+GVizjpnnJPCErUm
> z(~py#01%ck2asI=5SB3ogcab#=?eJBr4{72%hYuq1akuw_HYtNmI2frgB`4tK#Ur;
> zF6x6XH@P+_Ld&Pj=Khmtif_<#%m^#v8|1@fDley8DqbpRJ8##35S;)CLQU5(s-g1&
> zGH1b11D=)VWpyG#bwi0++xi+Rry%Bx8xX28AhXsD5b>@|GH+hjmxkvqUg|FRiNY&&
> zP6(%e4anlh3W@7JWKOd9E)p`E*!Jfr70=|kILq??taYC%vd4tW9O052 zQXTCpCkvg$z92;~u`^Cz|8;Ub$4U{W)axrh#`o>FwtHy(W1l^5)-!Q6rkeY2pcOb5
> zC5~Q^#`Cf!S&N9GM~?nelacMDHe;2ejYcV-D%(M~7r|5FJ&7hOIQ$Oo!_o8>9i>^x
> zV>X-Uc!7Jfq5+jI?0J=nn!sj`v1wMcU}PH?O>D8bJ*^GcSU|ak{Lxs!g8aAiFN}Pz
> A0RR91
>
> literal 0
> HcmV?d1
>
> --
> 2.32.0
>
> --
> 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: byte/char string representation (Was: [PATCH] Fix byte char and byte string lexing code)

[Philip Herron]

Hi Mark,

Thanks for clarifying this, I was getting mixed up between normal str's and
byte strings. Your patch was 99% of the way there to fix the type
resolution so I finished it off for you:

https://github.com/Rust-GCC/gccrs/pull/698/files

The missing piece was that References and Array's are a type of covariant
type so that an array type can look like this: [_, capacity], so the
inference variable here is the variant so that we need to make sure it has
its own implicit mapping id. You just needed to create one more mapping to
get that implicit id so that the reference type similarly doesn't get into
a loop of looking up itself. Creating implicit types like this could be
made easier, so we should likely add some helpers for this scenario.

Let me know what you think.

Thanks

--Phil

On Sat, 25 Sept 2021 at 12:53, Mark Wielaard  wrote:

> Hi Philip,
>
> On Fri, Sep 24, 2021 at 12:01:42PM +0100, Philip Herron wrote:
> > 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?
>
> I think the respresentation as std::string is fine. As long as we
> don't mix std::strings between different types (byte strings may
> contain sequences of chars that aren't valid utf-8 sequenecs).
>
> > 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.
>
> OK, so how do I represent an reference to an array type that doesn't
> contain any inference variables? When we see a b"hello" byte string
> that is the same as seeing &[b'h', b'e', b'l', b'l', b'o'] which is
> the same as seeing &[0x68u8, 0x65u8, 0x6cu8, 0x6cu8, 0x6fu8];
>
> So we know this is &[u8;5] and if we write:
>
> let a = b"hello";
>
> We want to infer that a has type &[u8;5].
>
> > 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]";
>
> Right, but that is for "proper strings". It is somewhat unfortunate
> that Rust calls byte strings also "strings", but they really
> aren't. b"abc" is static array of u8, not a &str (containing utf-8).
>
> I have to think about the slicing of "proper strings", which sound
> more complicated than slicing of byte strings, because I don't think
> you want to chop up a utf-8 sequence. For now I would simply try to
> get the type of byte strings like b"test" correct.
>
> Cheers,
>
> Mark
>
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Monthly Community Meeting

[Philip Herron]

Hi everyone,

Its that time again, tomorrow is our usual community meeting:

   - Date and Time 1st October 2021 at: 09h00 UTC
   - Agenda: https://hackmd.io/FBNWz8LyQk2vOaEsQtex1g please feel free to
   add agenda items you wish to see discussed.
   - Jitsi: https://meet.jit.si/259057065581073

If you cannot attend we will be taking notes as usual.

Thanks

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

Invitation: GCC Rust Community Call @ Fri 3 Dec 2021 2pm - 2:30pm (GMT) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20211203T14Z
DTEND:20211203T143000Z
DTSTAMP:20211202T092531Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:3dq5g3j6866euu2ogtt7av8...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=philip.her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.herron@embecosm
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=gcc-rust@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=simon.c...@embecosm.com;X-NUM-GUESTS=0:mailto:simon.cook@embecosm.c
 om
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=jeremy.benn...@embecosm.com;X-NUM-GUESTS=0:mailto:jeremy.bennett@em
 becosm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=philipp.kro...@embecosm.com;X-NUM-GUESTS=0:mailto:philipp.krones@em
 becosm.com
X-MICROSOFT-CDO-OWNERAPPTID:1000509693
CREATED:20211202T092530Z
DESCRIPTION:We will be having our 8th community call as the first Friday
  of the month:Date and Time 3rd December 2021 at: 14h00 UTCAgenda: https://hackmd.io/gp1sm9foR3upyyvPhJ5ZLg"; id="ow340" 
 __is_owner="true">https://hackmd.io/gp1sm9foR3upyyvPhJ5ZLg please feel 
 free to add agenda items you wish to see discussed.Jitsi: https://meet.jit.si/259057065581073";>https://meet.jit.si/259057065581073\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~::~:~::-\nDo not edit this section of the description.\
 n\nThis event has a video call.\nJoin: https://meet.google.com/qpk-jjsh-yot
 \n(GB) +44 20 3956 6358 PIN: 974811870#\nView more phone numbers: https://t
 el.meet/qpk-jjsh-yot?pin=8017102305047&hs=7\n\nView your event at https://c
 alendar.google.com/calendar/event?action=VIEW&eid=M2RxNWczajY4NjZldXUyb2d0d
 DdhdjhzMDUgZ2NjLXJ1c3RAZ2NjLmdudS5vcmc&tok=MjYjcGhpbGlwLmhlcnJvbkBlbWJlY29z
 bS5jb205OWI5OGVhODljNGNhNWFmOTkzNzVjNjg4M2Q1MzE5MDI1YzllYjkz&ctz=Europe%2FL
 ondon&hl=en_GB&es=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20211202T092530Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:GCC Rust Community Call
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Updated invitation with note: GCC Rust Community Call @ Fri 3 Dec 2021 2pm - 2:30pm (GMT) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20211203T14Z
DTEND:20211203T143000Z
DTSTAMP:20211202T092643Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:3dq5g3j6866euu2ogtt7av8...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=philip.her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.herron@embecosm
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=gcc-rust@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=simon.c...@embecosm.com;X-NUM-GUESTS=0:mailto:simon.cook@embecosm.c
 om
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=jeremy.benn...@embecosm.com;X-NUM-GUESTS=0:mailto:jeremy.bennett@em
 becosm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=philipp.kro...@embecosm.com;X-NUM-GUESTS=0:mailto:philipp.krones@em
 becosm.com
X-MICROSOFT-CDO-OWNERAPPTID:1000509693
CREATED:20211202T092530Z
DESCRIPTION:We will be having our 8th community call as the first Friday
  of the month:Date and Time 3rd December 2021 at: 14h00 UTCAgenda: https://hackmd.io/gp1sm9foR3upyyvPhJ5ZLg"; id="ow340" 
 __is_owner="true">https://hackmd.io/gp1sm9foR3upyyvPhJ5ZLg please feel 
 free to add agenda items you wish to see discussed.Jitsi: https://meet.jit.si/259057065581073";>https://meet.jit.si/259057065581073\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~::~:~::-\nDo not edit this section of the description.\
 n\nView your event at https://calendar.google.com/calendar/event?action=VIE
 W&eid=M2RxNWczajY4NjZldXUyb2d0dDdhdjhzMDUgZ2NjLXJ1c3RAZ2NjLmdudS5vcmc&tok=M
 jYjcGhpbGlwLmhlcnJvbkBlbWJlY29zbS5jb205OWI5OGVhODljNGNhNWFmOTkzNzVjNjg4M2Q1
 MzE5MDI1YzllYjkz&ctz=Europe%2FLondon&hl=en_GB&es=0.\n-::~:~::~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20211202T092642Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:GCC Rust Community Call
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

GCC Rust development Visualized

[Philip Herron]

Hi everyone,

I created a script to isolate as best I could all of our work on GCC
Rust to visualize the compiler's progress and our cargo integration
within the GCC tree; please find the link at the bottom of this
message to YouTube.

I want to say it's been an incredible year because so many of you have
decided to join in the journey of developing a front-end for GCC. I
appreciate all of the hard work everyone put in to help out this year
and even those who helped answer all my questions about Rust. Overall
thank you so much, everyone; roll on 2022 for another year of
development.

https://www.youtube.com/watch?v=QkdGY9VljTc

Thanks

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

GCC Rust 2021

[Philip Herron]

Hi everyone,

I have made a report reviewing the year 2021. You can find it here:
https://thephilbert.io/2021/12/20/gcc-rust-in-2021/ or on GitHub:
https://github.com/Rust-GCC/Reporting/blob/main/2021-year-report.org

I wish everyone happy healthy holidays! Please take care of yourselves
and thanks for making 2021 awesome!

Thanks

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

Invitation: GCC Rust Community Call @ Fri 14 Jan 2022 2pm - 2:30pm (GMT) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20220114T14Z
DTEND:20220114T143000Z
DTSTAMP:20220112T123614Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:2ltfsairclncuk0srcbbe9o...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=philip.her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.herron@embecosm
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=gcc-rust@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=simon.c...@embecosm.com;X-NUM-GUESTS=0:mailto:simon.cook@embecosm.c
 om
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=jeremy.benn...@embecosm.com;X-NUM-GUESTS=0:mailto:jeremy.bennett@em
 becosm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=philipp.kro...@embecosm.com;X-NUM-GUESTS=0:mailto:philipp.krones@em
 becosm.com
X-GOOGLE-CONFERENCE:https://meet.google.com/bdi-pziv-dkq
X-MICROSOFT-CDO-OWNERAPPTID:-1729552348
CREATED:20220112T123613Z
DESCRIPTION:Hi everyone\,It's that time again for our community cal
 l.Date and Time 14th January 2022 at 14h00 UTCAgen
 da: https://hackmd.io/DsFmFtzEQ1STDkXdDNlUXQ";>https://hackmd.io/Ds
 FmFtzEQ1STDkXdDNlUXQ  please feel free to add agenda items you wish to 
 see discussed.Jitsi: https://meet.jit.si/ArtificialPantsF
 lashNeither" id="ow336" __is_owner="true">https://meet.jit.si/ArtificialPan
 tsFlashNeitherFeel free to suggest things to talk about o
 n the agenda I will be updating this later today.Thanks--Ph
 il\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~::~:~::-\nDo not edit this section of the description.\n\nThis ev
 ent has a video call.\nJoin: https://meet.google.com/bdi-pziv-dkq\n(GB) +44
  20 3957 2381 PIN: 569141622#\nView more phone numbers: https://tel.meet/bd
 i-pziv-dkq?pin=4570305896508&hs=7\n\nView your event at https://calendar.go
 ogle.com/calendar/event?action=VIEW&eid=Mmx0ZnNhaXJjbG5jdWswc3JjYmJlOW9scTY
 gZ2NjLXJ1c3RAZ2NjLmdudS5vcmc&tok=MjYjcGhpbGlwLmhlcnJvbkBlbWJlY29zbS5jb21hN2
 VhYjM0MWZjZjRjY2Y1NjBhYjg4ZTFlMDY5OWMwNjBhMTU0MTY3&ctz=Europe%2FLondon&hl=e
 n_GB&es=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20220112T123613Z
LOCATION:https://meet.jit.si/ArtificialPantsFlashNeither
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:GCC Rust Community Call
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: make check-rust doesn't fail, but now the buildbot does

[Philip Herron]

Thanks for doing this I've been investigating the issue with the 2
match expressions I think it's down to the layout of the enum type not
being correct. Not quite sure what the fix will be yet.

Overall it's just great to have this level of feedback automatically
on multiple machines.

--Phil

On Tue, 22 Feb 2022 at 23:59, Mark Wielaard  wrote:
>
> Hi,
>
> make check-rust doesn't fail if there are any unexpected failuress.
> I couldn't figure out why not. So I added a new step to the buildbot
> so that it does grep unexpected gcc/testsuite/rust/rust.sum; test $? == 1"
> which should make the build fail if there are any unexpected test results.
>
> If this works at least the debian-i686 builder should start failing
> because it has a couple of failing test results.
>
> Cheers,
>
> Mark
>
> --
> 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

qual_union_type help

[Philip Herron]

Hi everyone

I am seeking some help on using the QUAL_UNION_TYPE it seems ideally
placed to be used for enums in Rust. My initial implementation was
achieved by simply using a union such as:

union my_enum {
  variant_a { enum discriminant; ...data } ;
  variant_b { enum discriminant; ...data} ;
}

Having each variant contain an enum for the discriminant meant that
dataless handling variants were quite simple. Upon trying to use the
QUAL_UNION_TYPE this all seems reasonably trivial but I can't figure
out what to set the DECL_QUALIFIER to be, initially from reading the
documentation on https://gcc.gnu.org/onlinedocs/gccint/Types.html it
seemed that it wants a slightly different layout by using a
placeholder_expr to reference an outer discriminant field such that
the layout becomes:

struct my_enum {
  enum discriminant;
  union variants {
variant_a { data };
variant_b { data };
  }
}

So I have been creating my DECL_QUALIFIER as follows:

```
tree field_offset = NULL_TREE;
tree place_holder = build0 (PLACEHOLDER_EXPR, sizetype);
tree place_holder_expr
  = build3 (COMPONENT_REF, TREE_TYPE (qual_field),
place_holder, qual_field, field_offset);

DECL_QUALIFIER (field)
= build2 (EQ_EXPR, boolean_type_node,
place_holder_expr, discrim);
```

So this seems to generate some interesting code and then finally hit
an ICE inside:

Breakpoint 5, gimplify_expr (expr_p=0x76ff1f48,
pre_p=0x7fffd2d8, post_p=0x7fffbb58, gimple_test_f=0x15aa98f
, fallback=3) at
../../gccrs/gcc/gimplify.cc:15755
15755 gcc_unreachable ();
(gdb) call debug_tree(*expr_p)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1
canonical-type 0x7700a000 precision:64 min  max >
   >

This makes sense this we can't gimplify a placeholder expression. So
this seems that when i make a constructor for the QUAL_UNION_TYPE i
must iterate the fields and replace the placeholder_expr to have a
reference to the discriminant via another COMPONENT_REF. Though does
this mean for the constructor i will need to create a temporary to
hold onto it to create another component_ref?

Or am I doing this completely wrong? I haven't had much success in
following the QUAL_UNION_TYPE code in the Ada front-end, but any
pointers would be greatly appreciated.

Thanks.

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

Re: qual_union_type help

[Philip Herron]

Hi Eric,

That makes sense during construction we also know what the value of
the discriminant is. What does the Ada front-end replace the
placeholder_exprs with? Can it simply be the value of the discriminant
at constructor? I haven't tried that.

Thanks

--Phil

On Wed, 23 Feb 2022 at 17:33, Eric Botcazou  wrote:
>
> > This makes sense this we can't gimplify a placeholder expression. So
> > this seems that when i make a constructor for the QUAL_UNION_TYPE i
> > must iterate the fields and replace the placeholder_expr to have a
> > reference to the discriminant via another COMPONENT_REF. Though does
> > this mean for the constructor i will need to create a temporary to
> > hold onto it to create another component_ref?
>
> The Ada compiler gets rid of all PLACEHOLDER_EXPRs in CONSTRUCTORs because the
> subtype of these CONSTRUCTORs is always constrained in Ada parlance, i.e. you
> know the value of the discriminant since it is assigned in the CONSTRUCTOR, so
> the gimplifier is indeed presumably not wired to eliminate them on its own.
>
> --
> Eric Botcazou
>
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Invitation: GCC Rust Community Call @ Fri 4 Mar 2022 2pm - 2:30pm (GMT) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20220304T14Z
DTEND:20220304T143000Z
DTSTAMP:20220301T172805Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:7goouts4uf656g6ic0of4hp...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=gcc-rust@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=philip.her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.herron@embecosm
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=philipp.kro...@embecosm.com;X-NUM-GUESTS=0:mailto:philipp.krones@em
 becosm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=arthur.co...@embecosm.com;X-NUM-GUESTS=0:mailto:arthur.cohen@embeco
 sm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=jeremy.benn...@embecosm.com;X-NUM-GUESTS=0:mailto:jeremy.bennett@em
 becosm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=simon.c...@embecosm.com;X-NUM-GUESTS=0:mailto:simon.cook@embecosm.c
 om
X-MICROSOFT-CDO-OWNERAPPTID:-1148383427
CREATED:20220301T172804Z
DESCRIPTION:Hi everyone\,Its that time again:- Date and Tim
 e 4th March 2022 at:14h00 UTC- Agenda: https://hackmd.io/KkrXwApIQg
 WwaUL8fl1Yrg?both- Jitsi: https://meet.jit.si/ArtificialPan
 tsFlashNeitherHope everyone has a great week.
 Thanks--Phil\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nDo not edit this section of the descr
 iption.\n\nView your event at https://calendar.google.com/calendar/event?ac
 tion=VIEW&eid=N2dvb3V0czR1ZjY1Nmc2aWMwb2Y0aHB0MHIgZ2NjLXJ1c3RAZ2NjLmdudS5vc
 mc&tok=MjYjcGhpbGlwLmhlcnJvbkBlbWJlY29zbS5jb205YTE1YTZjNmM1NGVkNjcwMjM1MjU0
 MzQ5NmVmZWMzMjJiZDY0NGQz&ctz=Europe%2FLondon&hl=en_GB&es=1.\n-::~:~::~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20220301T172804Z
LOCATION:https://meet.jit.si/ArtificialPantsFlashNeither
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:GCC Rust Community Call
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Buildbot failure in Wildebeest Builder on whole buildset

[Philip Herron]

Yet again the build bots are out doing github automation :D. Would you
be able to give Arthur access to the failing buildbot to test his fix?
We think we know what the issue is. We changed the lexer so we could
give it a buffer instead of a file for macro expansion, but the string
is going out of scope when we set it up.

Thanks

--Phil

On Wed, 2 Mar 2022 at 07:21, Thomas Schwinge  wrote:
>
> Hi!
>
> On 2022-03-02T00:15:41+0100, Mark Wielaard  wrote:
> > On Tue, Mar 01, 2022 at 07:08:15PM +, build...@builder.wildebeest.org 
> > wrote:
> >> The Buildbot has detected a new failure on builder gccrust-debian-arm64 
> >> while building gccrust.
> >> Full details are available at:
> >> https://builder.wildebeest.org/buildbot/#builders/58/builds/1710
> >>
> >> Buildbot URL: https://builder.wildebeest.org/buildbot/
> >>
> >> Worker for this Build: debian-arm64
> >>
> >> Build Reason: 
> >> Blamelist: Arthur Cohen 
> >>
> >> BUILD FAILED: failed compile (failure)
> >
> > And the same for all other builders.
>
> ... and me: 
> "'[...]/gcc/rust/parse/rust-cfg-parser.cc:67: rust_cfg_parser_test:
> FAIL: ASSERT_TRUE ((Rust::parse_cfg_option (input, key, value)))'".
>
> > I haven't figured out yet why the last commit caused this.
>
> (Same here.)
>
> > But it can be replicated when configuring with --enable-checking=yes
>
> That's strange -- isn't some '--enable-checking=[...]' actually the
> default for GCC builds?
>
> > That causes the selftests to trigger:
>
> At least we can see that the GCC/Rust self-tests are executing!  ;-P
>
>
> Grüße
>  Thomas
>
>
> > make[2]: Entering directory '/home/mark/build/gccrs-obj/gcc'
> > /home/mark/build/gccrs-obj/./gcc/xgcc -B/home/mark/build/gccrs-obj/./gcc/ 
> > -xrs -nostdinc /dev/null -S -o /dev/null 
> > -fself-test=/home/mark/src/gccrs/gcc/testsuite/selftests
> > rust1: error: unexpected character ‘1’
> > rust1: error: unexpected character ‘0’
> > rust1: error: unexpected character ‘0’
> > rust1: error: unexpected character ‘0’
> > rust1: error: unexpected character ‘1’
> > rust1: error: unexpected character ‘0’
> > rust1: error: unexpected character ‘0’
> > rust1: error: unexpected character ‘0’
> > rust1: error: unexpected character ‘e0’
> > rust1: error: unexpected character ‘d3’
> > rust1: error: unexpected character ‘89’
> > /home/mark/src/gccrs/gcc/rust/parse/rust-cfg-parser.cc:68: 
> > rust_cfg_parser_test: FAIL: ASSERT_EQ ((key), ("key_no_value"))
> > rust1: internal compiler error: in fail, at selftest.cc:47
> > 0x1cf096b selftest::fail(selftest::location const&, char const*)
> >   /home/mark/src/gccrs/gcc/selftest.cc:47
> > 0x7bb9a3 selftest::rust_cfg_parser_test()
> >   /home/mark/src/gccrs/gcc/rust/parse/rust-cfg-parser.cc:68
> > 0x1c143b7 selftest::run_tests()
> >   /home/mark/src/gccrs/gcc/selftest-run-tests.cc:119
> > 0xf1310b toplev::run_self_tests()
> >   /home/mark/src/gccrs/gcc/toplev.cc:2217
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > Please include the complete backtrace with any bug report.
> > See  for instructions.
> > make[2]: *** [/home/mark/src/gccrs/gcc/rust/Make-lang.in:232: 
> > s-selftest-rust] Error 1
> > make[2]: Leaving directory '/home/mark/build/gccrs-obj/gcc'
> >
> > Cheers,
> >
> > Mark
> >
> > --
> > Gcc-rust mailing list
> > Gcc-rust@gcc.gnu.org
> > https://gcc.gnu.org/mailman/listinfo/gcc-rust
> -
> 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
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Invitation: GCC Rust community call @ Fri 1 Apr 2022 3pm - 3:30pm (BST) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20220401T14Z
DTEND:20220401T143000Z
DTSTAMP:20220330T101558Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:0os8pduuhtouiutsi9v9cmp...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=philipp.kro...@embecosm.com;X-NUM-GUESTS=0:mailto:philipp.krones@em
 becosm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=philip.her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.herron@embecosm
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=arthur.co...@embecosm.com;X-NUM-GUESTS=0:mailto:arthur.cohen@embeco
 sm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=jeremy.benn...@embecosm.com;X-NUM-GUESTS=0:mailto:jeremy.bennett@em
 becosm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=simon.c...@embecosm.com;X-NUM-GUESTS=0:mailto:simon.cook@embecosm.c
 om
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=gcc-rust@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
X-GOOGLE-CONFERENCE:https://meet.google.com/ryc-vuox-rkq
X-MICROSOFT-CDO-OWNERAPPTID:-555941746
CREATED:20220330T101557Z
DESCRIPTION:Hi everyoneIts that time again for our community cal
 l this Friday:Date and Time 1st April at: 14h00 UTCAgenda:
  \;https://hackmd.io/xsCkyWQ-Sp6jzczS6rz8RQ";>https://ha
 ckmd.io/xsCkyWQ-Sp6jzczS6rz8RQ \;please feel free to a
 dd agenda items you wish to see discussed.Jitsi: \;https://meet.jit.si/gccrs-community-call";>https://meet.jit.si/gccrs-c
 ommunity-callThanks--Phil\n\n-::~:~::~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nDo not edit 
 this section of the description.\n\nThis event has a video call.\nJoin: htt
 ps://meet.google.com/ryc-vuox-rkq\n(GB) +44 20 3956 9698 PIN: 137268065#\nV
 iew more phone numbers: https://tel.meet/ryc-vuox-rkq?pin=6878209672117&hs=
 7\n\nView your event at https://calendar.google.com/calendar/event?action=V
 IEW&eid=MG9zOHBkdXVodG91aXV0c2k5djljbXA3a2YgZ2NjLXJ1c3RAZ2NjLmdudS5vcmc&tok
 =MjYjcGhpbGlwLmhlcnJvbkBlbWJlY29zbS5jb204MWRmYjhjM2YwZTc5MzNmMThlODhlNzc5Zm
 EwOGFiMGEzY2M1ZjU4&ctz=Europe%2FLondon&hl=en_GB&es=1.\n-::~:~::~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20220330T101557Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:GCC Rust community call
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Bad testcase

[Philip Herron]

Hi everyone,

We merged a new builtin macro recently and during the code review we
missed a case where the code produces an infinite loop and so we
raised: https://github.com/Rust-GCC/gccrs/issues/1102

The GitHub CI did not seem to catch this issue, I am assuming dejagnu
timeout the test case and our CI doesn't pick this up as a failure and
so I have pushed a patch directly to master to disable the offending
test case. I am raising this here just for transparency for why I
pushed to master and I hope the build farm is ok it might be worth
cancelling any existing builds and letting them pick up the next
merge's to master. For reference I pushed this patch to silence the
issue: 68458036c81d141a3899ac4e6ec6ddf0fdfde174

Hope everyone is having a great start of the week.

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

Re: Bad testcase

[Philip Herron]

For reference we found that the testsuite does timeout the test-case
and produces;

```
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /home/runner/work/gccrs/gccrs/gcc/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running /home/runner/work/gccrs/gccrs/gcc/testsuite/rust/compile/compile.exp ...
max length for a Tcl unicode value (2147483637 chars) exceeded
/bin/bash: line 21: 92574 Aborted (core dumped) `if [ -f
${srcdir}/../dejagnu/runtest ] ; then echo
${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool rust
make[2]: Leaving directory '/home/runner/work/gccrs/gccrs/gccrs-build/gcc'
make[1]: Leaving directory '/home/runner/work/gccrs/gccrs/gccrs-build/gcc'
```

It's a pity make check-rust does fail properly here but hopefully,
someone knows of a nice way to handle this.

Thanks

--Phil

On Mon, 11 Apr 2022 at 11:35, Philip Herron  wrote:
>
> Hi everyone,
>
> We merged a new builtin macro recently and during the code review we
> missed a case where the code produces an infinite loop and so we
> raised: https://github.com/Rust-GCC/gccrs/issues/1102
>
> The GitHub CI did not seem to catch this issue, I am assuming dejagnu
> timeout the test case and our CI doesn't pick this up as a failure and
> so I have pushed a patch directly to master to disable the offending
> test case. I am raising this here just for transparency for why I
> pushed to master and I hope the build farm is ok it might be worth
> cancelling any existing builds and letting them pick up the next
> merge's to master. For reference I pushed this patch to silence the
> issue: 68458036c81d141a3899ac4e6ec6ddf0fdfde174
>
> Hope everyone is having a great start of the week.
>
> --Phil
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Regular Online GCC/Rust Meeting Time Slot

[Philip Herron]

Hello,

Thanks, for doing this I am tempted to suggest that we could have two
calls at two different time slots (one like our old time slot of
1000UTC then one later on) to allow US friends to join, I tend to work
late on Wednesdays anyway. But let's see the results of this poll I
would like to set up the call properly by tomorrow to avoid any
confusion.

Please take a moment to fill in your availability when you get a chance. Thanks.

--Phil

On Tue, 10 May 2022 at 07:21, Thomas Schwinge  wrote:
>
> Hi!
>
> We're trying to figure out a good regular online GCC/Rust meeting time
> slot.  Currently we're meeting once a month.
>
> It's been a bit difficult to find a (a) free online service that
> (b) doesn't work just with actual dates but generic days of week and
> (c) does consider different timezones...
>
> If you wish to participate in these calls, please on
>  submit your availability in a typical
> week.
>
>
> 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
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Invitation: GCC Rust community-call @ Fri 13 May 2022 10am - 10:30am (BST) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20220513T09Z
DTEND:20220513T093000Z
DTSTAMP:20220511T123644Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:6qk8sjt1tcp58la9kblet3a...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=arthur.co...@embecosm.com;X-NUM-GUESTS=0:mailto:arthur.cohen@embeco
 sm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=philip.her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.herron@embecosm
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=philipp.kro...@embecosm.com;X-NUM-GUESTS=0:mailto:philipp.krones@em
 becosm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=gcc-rust@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
X-GOOGLE-CONFERENCE:https://meet.google.com/hae-xskw-ces
X-MICROSOFT-CDO-OWNERAPPTID:-445955300
CREATED:20220511T123643Z
DESCRIPTION:Hi allIt's that time again for our community call this 
 Friday. Date and Time 13th May 2022 at: 09h00 UTCAgenda: https://hackmd.io/ljuSwxP2Qn-oKf5jF_V2UA";>https://ha
 ckmd.io/ljuSwxP2Qn-oKf5jF_V2UA please feel free to add agenda items you
  wish to see discussed.Jitsi: https://meet.ji
 t.si/gccrs-community-call" id="ow1696" __is_owner="true">https://meet.jit.s
 i/gccrs-community-call \;This moves the
  call back to our old time slot which seems to suit people better. In order
  to accommodate our friends in the US timezone\, I will be hosting a separa
 te call on Wednesday\, details will be announced for that in the next repor
 t. \;  \;Thanks--Phil\n\n-::~:~::~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nDo not edit 
 this section of the description.\n\nThis event has a video call.\nJoin: htt
 ps://meet.google.com/hae-xskw-ces\n(GB) +44 20 3956 9493 PIN: 263965918#\nV
 iew more phone numbers: https://tel.meet/hae-xskw-ces?pin=6346729388270&hs=
 7\n\nView your event at https://calendar.google.com/calendar/event?action=V
 IEW&eid=NnFrOHNqdDF0Y3A1OGxhOWtibGV0M2FuaDEgZ2NjLXJ1c3RAZ2NjLmdudS5vcmc&tok
 =MjYjcGhpbGlwLmhlcnJvbkBlbWJlY29zbS5jb20zOTNkYmIwMjgwZWMzNjA4ZTA1ZjFmMWM3Mz
 E3MmQxMmNiZmJhZGE2&ctz=Europe%2FLondon&hl=en_GB&es=1.\n-::~:~::~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20220511T123643Z
LOCATION:https://meet.jit.si/gccrs-community-call
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:GCC Rust community-call
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: ☝ Buildbot (GNU Toolchain): gccrust - worker cancelled (master)

[Philip Herron]

Hi Mark,

A full bootstrap once a day might be nice to have actually. I wonder
how long it will take on this build bot.

Hopefully, the bots don't unionize and go on strike for being overworked :).

--Phil

On Tue, 24 May 2022 at 02:30, Mark Wielaard  wrote:
>
> Hi,
>
> On Tue, May 24, 2022 at 01:01:55AM +, builder--- via Gcc-rust wrote:
> > A cancelled build has been detected on builder gccrust-fedora-x86_64 while 
> > building gccrust.
> >
> > Full details are available at:
> > https://builder.sourceware.org/buildbot/#builders/16/builds/131
> >
> > Build state: worker cancelled
> > Revision: (unknown)
> > Worker: bb2
> > Build Reason: (unknown)
> > Blamelist: Philip Herron 
> >
> > Steps:
> >
> > - 0: worker_preparation ( cancelled )
>
> Apologies, that was me playing with the new container image builder.
> It all works now. And the now builder seems fast enough to maybe do a
> full bootstrap build (once a day?)
>
> Cheers,
>
> Mark
>
> --
> 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

Invitation: Rust GCC community call @ Fri 10 Jun 2022 10am - 11am (BST) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20220610T09Z
DTEND:20220610T10Z
DTSTAMP:20220607T090003Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:2hquvr1alff4ka2ki76c93q...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=gcc-rust@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=philip.her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.herron@embecosm
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=arthur.co...@embecosm.com;X-NUM-GUESTS=0:mailto:arthur.cohen@embeco
 sm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=phil...@recogni.com;X-NUM-GUESTS=0:mailto:phil...@recogni.com
X-MICROSOFT-CDO-OWNERAPPTID:-273159294
CREATED:20220607T090001Z
DESCRIPTION:Hi everyoneIts that time again f
 or the community call:Date and Time 10th June 2022
  at: \; \;Fri\, Jun 10 2022\
 , 10:00 UTCAgenda: \;https://
 hackmd.io/xWN5fFdWTPWgFa-Tny-jNg \;please feel f
 ree to add agenda items you wish to see discussed.Jitsi: \;https://meet.jit.si/gccrs-community-call";
  id="ow342" __is_owner="true">https://meet.jit.si/gccrs-community-call<
 br>Thanks--Philhttps://meet.jit.si/gccrs-commu
 nity-call" id="ow342" __is_owner="true">\n\n-::~:~::~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nDo not edit t
 his section of the description.\n\nView your event at https://calendar.goog
 le.com/calendar/event?action=VIEW&eid=MmhxdXZyMWFsZmY0a2Eya2k3NmM5M3EyODggZ
 2NjLXJ1c3RAZ2NjLmdudS5vcmc&tok=MjYjcGhpbGlwLmhlcnJvbkBlbWJlY29zbS5jb21kYzU5
 YTM1MjMwZTQ1ZjE1MmYwYTkxZTQ5M2RlOWExODA3NmQwMTU5&ctz=Europe%2FLondon&hl=en_
 GB&es=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20220607T090002Z
LOCATION:https://meet.jit.si/gccrs-community-call
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Rust GCC community call
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Updated invitation: Rust GCC community call @ Fri 10 Jun 2022 10am - 10:30am (BST) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20220610T09Z
DTEND:20220610T093000Z
DTSTAMP:20220607T090013Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:2hquvr1alff4ka2ki76c93q...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=gcc-rust@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=philip.her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.herron@embecosm
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=arthur.co...@embecosm.com;X-NUM-GUESTS=0:mailto:arthur.cohen@embeco
 sm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=phil...@recogni.com;X-NUM-GUESTS=0:mailto:phil...@recogni.com
X-MICROSOFT-CDO-OWNERAPPTID:-273159294
CREATED:20220607T090001Z
DESCRIPTION:Hi everyoneIts that time again f
 or the community call:Date and Time 10th June 2022
  at: \; \;Fri\, Jun 10 2022\
 , 10:00 UTCAgenda: \;https://
 hackmd.io/xWN5fFdWTPWgFa-Tny-jNg \;please feel f
 ree to add agenda items you wish to see discussed.Jitsi: \;https://meet.jit.si/gccrs-community-call";
  id="ow342" __is_owner="true">https://meet.jit.si/gccrs-community-call<
 br>Thanks--Philhttps://meet.jit.si/gccrs-commu
 nity-call" id="ow342" __is_owner="true">\n\n-::~:~::~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nDo not edit t
 his section of the description.\n\nView your event at https://calendar.goog
 le.com/calendar/event?action=VIEW&eid=MmhxdXZyMWFsZmY0a2Eya2k3NmM5M3EyODggZ
 2NjLXJ1c3RAZ2NjLmdudS5vcmc&tok=MjYjcGhpbGlwLmhlcnJvbkBlbWJlY29zbS5jb21kYzU5
 YTM1MjMwZTQ1ZjE1MmYwYTkxZTQ5M2RlOWExODA3NmQwMTU5&ctz=Europe%2FLondon&hl=en_
 GB&es=0.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20220607T090012Z
LOCATION:https://meet.jit.si/gccrs-community-call
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Rust GCC community call
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Updated invitation with note: Rust GCC community call @ Fri 10 Jun 2022 10am - 10:30am (BST) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20220610T09Z
DTEND:20220610T093000Z
DTSTAMP:20220608T143049Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:2hquvr1alff4ka2ki76c93q...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=gcc-rust@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=philip.her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.herron@embecosm
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=arthur.co...@embecosm.com;X-NUM-GUESTS=0:mailto:arthur.cohen@embeco
 sm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=phil...@recogni.com;X-NUM-GUESTS=0:mailto:phil...@recogni.com
X-MICROSOFT-CDO-OWNERAPPTID:-273159294
CREATED:20220607T090001Z
DESCRIPTION:Hi everyoneIts that t
 ime again for the community call:Date and Time 10t
 h June 2022 at: \; \;Fri\, 
 Jun 10 2022\, 09:00 UTCAgenda: \;<
 a href="https://hackmd.io/xWN5fFdWTPWgFa-Tny-jNg";>https://hackmd.io/xWN5fFd
 WTPWgFa-Tny-jNg \;please feel free to add agenda
  items you wish to see discussed.Jitsi: \;https://meet.jit.si/gccrs-community-call";>https://meet.jit
 .si/gccrs-community-callThanks--Phil\n\n-::~:~::~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nD
 o not edit this section of the description.\n\nView your event at https://c
 alendar.google.com/calendar/event?action=VIEW&eid=MmhxdXZyMWFsZmY0a2Eya2k3N
 mM5M3EyODggZ2NjLXJ1c3RAZ2NjLmdudS5vcmc&tok=MjYjcGhpbGlwLmhlcnJvbkBlbWJlY29z
 bS5jb21kYzU5YTM1MjMwZTQ1ZjE1MmYwYTkxZTQ5M2RlOWExODA3NmQwMTU5&ctz=Europe%2FL
 ondon&hl=en_GB&es=0.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20220608T143047Z
LOCATION:https://meet.jit.si/gccrs-community-call
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Rust GCC community call
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Rust front-end

[Philip Herron]

Hi everyone,

Since November 2020, I've worked full-time on the Rust front-end for
GCC, thanks to Open Source Security, Inc and Embecosm. As a result, I
am writing to this mailing list to seek feedback from the collective
experience here early to plan a path for upstreaming the front-end
into GCC.

1. What is the actual process of merging a prominent feature like this upstream
  - How do we review this?
  - Do we create a "mega-commit" patch
  - How long should we expect this review process to take
  - Is there anything we can do to make this easier?

2. What sort of quality does the GCC community expect?
  - I think it is essential that we can compile valid test cases from
a testsuite and real projects before merging.
  - It seems reasonable that our error handling may not be 100% but be
expected to improve over time
  - Upon merging, can features like Rust be marked as experimental

3. How do GCC releases work?
  - If you miss a window can we still merge code into the front-end?
  - Can we merge without a borrow checker and backport this in the future?

4. What about the possibility of merging sooner rather than later,
which would help the project gain interest through the increased
visibility of it as part of the GCC family.
  - Does this still allow for development churn, or will it cause friction?

5. Does anyone have prior experience or advice they could give us?

For some context, my current project plan brings us to November 2022
where we (unexpected events permitting) should be able to support
valid Rust code targeting Rustc version ~1.40 and reuse libcore,
liballoc and libstd. This date does not account for the borrow checker
feature and the proc macro crate, which we have a plan to implement,
but this will be a further six-month project.

Regarding patch management, we currently do our development on GitHub:
https://github.com/Rust-GCC/gccrs; this means we can integrate our
issue tracking with the official Rust project by linking back to the
official Rust project's RFC issues, for example. The downside is that
when someone uses our compiler and hits an ICE, they will be directed
to the GCC Bugzilla, which is correct but can lead to a mismatch in
issue tracking. Nevertheless, I think it's essential to have the
GitHub link here to integrate with the broader Rust community. I
believe we can triage Rust issues on the Bugzilla and raise associated
ones on Github to manage this.

From my perspective as the lead on this front-end, we are currently
under heavy development, so this means a fair amount of code churn
still, and I don't see this changing until we can successfully compile
the libcore crate later this year. Although I would love to see us
merged into GCC 13, I want to make sure this project is a success for
everyone, and this might mean pushing back to the next release window
to make sure this is manageable to produce a quality front-end to sit
alongside the others.

I wish to thank you those in the GCC developer community, who have
inspired me and helped me navigate my journey to this point in time.

- Thomas Schwinge
- Mark Wielaard
- Tom Tromey
- Ian Lance Taylor
- David Edelsohn
- David Malcolm
- Martin Jambor

Thanks

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

Invitation: GCC Rust community call @ Fri 1 Jul 2022 10am - 10:30am (BST) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20220701T09Z
DTEND:20220701T093000Z
DTSTAMP:20220627T151714Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:700eo29icvg5k3rpa1b4aki...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=gcc-rust@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=philip.her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.herron@embecosm
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=arthur.co...@embecosm.com;X-NUM-GUESTS=0:mailto:arthur.cohen@embeco
 sm.com
X-MICROSOFT-CDO-OWNERAPPTID:621976092
CREATED:20220627T151712Z
DESCRIPTION:Hi everyone\,Its th
 at time again for our monthly community call (on-time :-)).<
 span> \; - Date and Time 1st July 2022 at: \; \;Fri\, Jul 1 2022\, 0900 UTC&nb
 sp\; - Agenda: \;https://hackmd.io/L26Zcfs
 nT8q5YcadDSu1FQ">https://hackmd.io/L26ZcfsnT8q5YcadDSu1FQ&n
 bsp\;please feel free to add agenda items you wish to see discussed.
  \; - Jitsi: \;https://me
 et.jit.si/gccrs-community-callHope to see you there. Thanks
 --Philhttps://meet.jit.si/gccrs-community-call"; id="ow
 740" __is_owner="true">\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nDo not edit this section of th
 e description.\n\nView your event at https://calendar.google.com/calendar/e
 vent?action=VIEW&eid=NzAwZW8yOWljdmc1azNycGExYjRha2kxMGkgZ2NjLXJ1c3RAZ2NjLm
 dudS5vcmc&tok=MjYjcGhpbGlwLmhlcnJvbkBlbWJlY29zbS5jb20wNzFhZDkxYTJmMWI2N2Y3M
 GY3ZTU5YTE4N2JmYjU0ZWZiOWIxMzQy&ctz=Europe%2FLondon&hl=en_GB&es=1.\n-::~:~:
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~
 :~::-
LAST-MODIFIED:20220627T151713Z
LOCATION:https://meet.jit.si/gccrs-community-call
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:GCC Rust community call
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Invitation: GCC Rust hang out @ Weekly from 7pm to 7:30pm on Wednesday (BST) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Europe/London
X-LIC-LOCATION:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19700329T01
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+
TZNAME:GMT
DTSTART:19701025T02
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/London:20220629T19
DTEND;TZID=Europe/London:20220629T193000
RRULE:FREQ=WEEKLY;BYDAY=WE
DTSTAMP:20220627T153913Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:4tl63v6qndrq0l26aisn0b4...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=philip.her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.herron@embecosm
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=gcc-rust@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
X-MICROSOFT-CDO-OWNERAPPTID:218830682
CREATED:20220627T153912Z
DESCRIPTION:Hi everyone\n\nThis is a regular call for anyone to drop in and
  talk about gccrs\, it should suit some people better with this time.\n\nWe
  will reuse our jitsi link: https://meet.jit.si/gccrs-community-call\n \n \
 nThanks\n\n--Phil\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nDo not edit this section of the descript
 ion.\n\nView your event at https://calendar.google.com/calendar/event?actio
 n=VIEW&eid=NHRsNjN2NnFuZHJxMGwyNmFpc24wYjRnNWogZ2NjLXJ1c3RAZ2NjLmdudS5vcmc&
 tok=MjYjcGhpbGlwLmhlcnJvbkBlbWJlY29zbS5jb21jZTllZWZiMzFkOWE1YmFkNDdlYzQ1ZGN
 iZWRjMzY0NWI2ZTZmZWUw&ctz=Europe%2FLondon&hl=en_GB&es=1.\n-::~:~::~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20220627T153912Z
LOCATION:https://meet.jit.si/gccrs-community-call
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:GCC Rust hang out
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Cancelled event with note: GCC Rust hang out @ Wed 6 Jul 2022 7pm - 7:30pm (BST) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:Europe/London
X-LIC-LOCATION:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19700329T01
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+
TZNAME:GMT
DTSTART:19701025T02
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/London:20220706T19
DTEND;TZID=Europe/London:20220706T193000
DTSTAMP:20220627T154013Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:4tl63v6qndrq0l26aisn0b4...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=philip
 .her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.her...@embecosm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=gc
 c-r...@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
RECURRENCE-ID;TZID=Europe/London:20220706T19
CREATED:20220627T153912Z
DESCRIPTION:Hi everyone\n\nThis is a regular call for anyone to drop in and
  talk about gccrs\, it should suit some people better with this time.\n\nWe
  will reuse our jitsi link: https://meet.jit.si/gccrs-community-call\n \n \
 nThanks\n\n--Phil
LAST-MODIFIED:20220627T154011Z
LOCATION:https://meet.jit.si/gccrs-community-call
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:GCC Rust hang out
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Rust front-end

[Philip Herron]

Hi Richard

Thanks for your detailed response, I took some time to figure this out
myself to give a decent response. It seems like we should keep the end
of the year as our goal to aim for but in the meantime see if we can
split patches which affect GCC over the next month or so. We have no
changes to the GCC gimple/generic IRs. Usually, when I hit something
inside the GCC middle-end, the front-end is doing something wrong,
which has helped keep me on a good path. Other than that we have
changes to:

1. Grabbing target info using the TARGET_HOOKS interfaces in gcc/config.
2. Tweaks to selftest which was already merged last year by Arthur Cohen
3. We have some minor issues with lang.opt in the latest merge from
upstream which Thomas Schwinge is working on, but I believe we can
work around this if we want
4. Our compiler driver needs some cleanup which we can do in the short
term to get it reviewed
5. We need to make some build changes to incorporate libcore being
built by gccrs which is still WIP.

As for the compile link cycle, we mostly reuse the model from the GO
front-end. In Rust the "crate" is a compilation unit, which means if
you have a project with multiple files, you point gccrs at a single
src/source.rs, the main entry point for a library (usually lib.rs).
Keywords such as "mod foo", trigger the expansion of a relative path
of foo.rs like a C++ included inside a namespace. All source files are
then included inside this single compilation unit. When the
compilation is successful, we reuse code from the Go front-end to put
custom front-end metadata into a section ".rust_export". At this
point, all source files are compiled into a single object file, which
can be compiled into an archive or shared library as required. To link
against this, it again follows similar to Go front-end, whereby the
source.rs has a declaration such as "extern crate foo"; the search
code will look for foo.o or libfoo.a (I haven't tested against shared
libraries yet) and grab the metadata out of it and parse it in the
front-end for all the necessary information such as types, public
functions and generics, etc., so we can compile any imports correctly
and emit the correct mangled symbols for linking.

Given we are still working on this I think we can try to line up all
the other GCC relating pieces for review over the summer, do we send
this as usual to gcc-patches?

Again thanks to everyone for helping me navigate this and answering my
questions.

--Phil

On Tue, 28 Jun 2022 at 08:30, Richard Biener  wrote:
>
> On Mon, Jun 27, 2022 at 4:52 PM Philip Herron
>  wrote:
> >
> > Hi everyone,
> >
> > Since November 2020, I've worked full-time on the Rust front-end for
> > GCC, thanks to Open Source Security, Inc and Embecosm. As a result, I
> > am writing to this mailing list to seek feedback from the collective
> > experience here early to plan a path for upstreaming the front-end
> > into GCC.
> >
> > 1. What is the actual process of merging a prominent feature like this 
> > upstream
> >   - How do we review this?
> >   - Do we create a "mega-commit" patch
> >   - How long should we expect this review process to take
> >   - Is there anything we can do to make this easier?
>
> Usually a new frontend is first proposed for merge and generally approved
> by the steering committee (which should also sort out legal issues).
>
> For the actual review process it's best to consult previous frontend
> merges - the most recent merged frontend was the D frontend and the
> modula2 frontend is in the process of being reviewed.
>
> To be able to focus on the possibly controversical pieces separating
> out changes to the generic GCC code base (such as driver or
> even middle-end) should be separated out.
>
> It would also be helpful to provide an overview of how a rust
> compile + link cycle works through the pieces in GCC (see the
> modula-2 case where that involved creating stub C++ code,
> compiling and linking that and how this is now done much
> more straight-forward).
>
> > 2. What sort of quality does the GCC community expect?
> >   - I think it is essential that we can compile valid test cases from
> > a testsuite and real projects before merging.
> >   - It seems reasonable that our error handling may not be 100% but be
> > expected to improve over time
> >   - Upon merging, can features like Rust be marked as experimental
>
> Rust can be marked as experimental, sure.  It would be not enabled
> to be built by default (and you can have a whitelist of supported targets).
> The most important part would be that the build works when enabled
> and that most of the existing testsuite passes so it can be used to
> regression test middle-end changes.
>
> If it is no

Cancelled event with note: GCC Rust hang out @ Wed 13 Jul 2022 7pm - 7:30pm (BST) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:Europe/London
X-LIC-LOCATION:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19700329T01
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+
TZNAME:GMT
DTSTART:19701025T02
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/London:20220713T19
DTEND;TZID=Europe/London:20220713T193000
DTSTAMP:20220713T164548Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:4tl63v6qndrq0l26aisn0b4...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=philip
 .her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.her...@embecosm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=gc
 c-r...@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
RECURRENCE-ID;TZID=Europe/London:20220713T19
CREATED:20220627T153912Z
DESCRIPTION:Hi everyone\n\nThis is a regular call for anyone to drop in and
  talk about gccrs\, it should suit some people better with this time.\n\nWe
  will reuse our jitsi link: https://meet.jit.si/gccrs-community-call\n \n \
 nThanks\n\n--Phil
LAST-MODIFIED:20220713T164547Z
LOCATION:https://meet.jit.si/gccrs-community-call
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:GCC Rust hang out
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Cancelled event: GCC Rust hang out @ Wed 20 Jul 2022 7pm - 7:30pm (BST) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:Europe/London
X-LIC-LOCATION:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19700329T01
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+
TZNAME:GMT
DTSTART:19701025T02
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/London:20220720T19
DTEND;TZID=Europe/London:20220720T193000
DTSTAMP:20220720T151702Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:4tl63v6qndrq0l26aisn0b4...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=philip
 .her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.her...@embecosm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=gc
 c-r...@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
RECURRENCE-ID;TZID=Europe/London:20220720T19
CREATED:20220627T153912Z
DESCRIPTION:Hi everyone\n\nThis is a regular call for anyone to drop in and
  talk about gccrs\, it should suit some people better with this time.\n\nWe
  will reuse our jitsi link: https://meet.jit.si/gccrs-community-call\n \n \
 nThanks\n\n--Phil
LAST-MODIFIED:20220720T151701Z
LOCATION:https://meet.jit.si/gccrs-community-call
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:GCC Rust hang out
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Cancelled event: GCC Rust hang out @ Wed 27 Jul 2022 7pm - 7:30pm (BST) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:Europe/London
X-LIC-LOCATION:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19700329T01
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+
TZNAME:GMT
DTSTART:19701025T02
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/London:20220727T19
DTEND;TZID=Europe/London:20220727T193000
DTSTAMP:20220727T154847Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:4tl63v6qndrq0l26aisn0b4...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=philip
 .her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.her...@embecosm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=gc
 c-r...@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
RECURRENCE-ID;TZID=Europe/London:20220727T19
CREATED:20220627T153912Z
DESCRIPTION:Hi everyone\n\nThis is a regular call for anyone to drop in and
  talk about gccrs\, it should suit some people better with this time.\n\nWe
  will reuse our jitsi link: https://meet.jit.si/gccrs-community-call\n \n \
 nThanks\n\n--Phil
LAST-MODIFIED:20220727T154846Z
LOCATION:https://meet.jit.si/gccrs-community-call
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:GCC Rust hang out
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Updated invitation with note: GCC Rust hang out @ Weekly from 7pm to 7:30pm on Wednesday from Wed 29 Jun to Tue 2 Aug (BST) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Europe/London
X-LIC-LOCATION:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19700329T01
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+
TZNAME:GMT
DTSTART:19701025T02
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/London:20220629T19
DTEND;TZID=Europe/London:20220629T193000
RRULE:FREQ=WEEKLY;UNTIL=20220802T225959Z;BYDAY=WE
DTSTAMP:20220803T164319Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:4tl63v6qndrq0l26aisn0b4...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=philip.her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.herron@embecosm
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=gcc-rust@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
X-MICROSOFT-CDO-OWNERAPPTID:218830682
CREATED:20220627T153912Z
DESCRIPTION:Hi everyone\n\nThis is a regular call for anyone to drop in and
  talk about gccrs\, it should suit some people better with this time.\n\nWe
  will reuse our jitsi link: https://meet.jit.si/gccrs-community-call\n \n \
 nThanks\n\n--Phil\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nDo not edit this section of the descript
 ion.\n\nView your event at https://calendar.google.com/calendar/event?actio
 n=VIEW&eid=NHRsNjN2NnFuZHJxMGwyNmFpc24wYjRnNWogZ2NjLXJ1c3RAZ2NjLmdudS5vcmc&
 tok=MjYjcGhpbGlwLmhlcnJvbkBlbWJlY29zbS5jb21jZTllZWZiMzFkOWE1YmFkNDdlYzQ1ZGN
 iZWRjMzY0NWI2ZTZmZWUw&ctz=Europe%2FLondon&hl=en_GB&es=0.\n-::~:~::~:~:~:~:~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20220803T164318Z
LOCATION:https://meet.jit.si/gccrs-community-call
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:GCC Rust hang out
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Invitation: Rust community call @ Fri 5 Aug 2022 10am - 10:30am (BST) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20220805T09Z
DTEND:20220805T093000Z
DTSTAMP:20220804T155029Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:3fbotvoh7u16brdu7t0vafu...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=gcc-rust@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=philip.her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.herron@embecosm
 .com
X-MICROSOFT-CDO-OWNERAPPTID:1802431959
CREATED:20220804T155027Z
DESCRIPTION:It is time for our next monthly community call:D
 ate: 5th August 2022 at: 09h00 UTCAgenda: https://hackmd.
 io/ZVgm1LaPQly173-OML2X7Q" id="ow313" __is_owner="true">https://hackmd.io/Z
 Vgm1LaPQly173-OML2X7QJitsi: https://meet.jit.si/gccrs
 -community-call" id="ow320" __is_owner="true">https://meet.jit.si/gccrs-com
 munity-call\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nDo not edit this section of the 
 description.\n\nView your event at https://calendar.google.com/calendar/eve
 nt?action=VIEW&eid=M2Zib3R2b2g3dTE2YnJkdTd0MHZhZnU3dm8gZ2NjLXJ1c3RAZ2NjLmdu
 dS5vcmc&tok=MjYjcGhpbGlwLmhlcnJvbkBlbWJlY29zbS5jb20zNDUwNDU1M2I1Yzc5ZWYxODR
 lY2U1YTIxZWQ0N2Y5MDUwNWM3OGM2&ctz=Europe%2FLondon&hl=en_GB&es=1.\n-::~:~::~
 :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~
 ::-
LAST-MODIFIED:20220804T155027Z
LOCATION:https://meet.jit.si/gccrs-community-call
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Rust community call
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Rust frontend patches v2

[Philip Herron]

Hi everyone

I noticed a few patches still didn't make it through here with the
400kb limit. In the meantime, Mark pointed out to me that they can all
be viewed over here:

https://inbox.sourceware.org/gcc-patches/20220824115956.737931-9-philip.her...@embecosm.com/T/#rbff0bb3df2780fecd9ee3d2baa864d9140d24b54

The missing patches on
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/thread.html#600200
are 8, 10, 13, 29, and 22.

Thanks let me know if there is anything more I can do to help.

--Phil

On Wed, 24 Aug 2022 at 13:01,  wrote:
>
> This is the 2nd patch set for gccrs, since v1 we have dropped the changes
> for target hooks which are not nessecary for us right now. This now
> focuses directly on the front-end the only patch that affects GCC now is a
> tweak to debug info. Note we are close to merging our port of the C++
> constexpr code into our front-end but this patch set does not include this
> yet.
>
> Thanks to Open Source Security, inc and Embecosm for sponsoring this work.
> Special thanks to all of those who have contributed thus far.
>
> See our branch over on 
> https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master
>
> We are currently testing on every commit the following systems:
>
> - Debian i386 - all tests passing
> - Debian testing-x86_64 - all tests passing
> - Fedora arm64 - all tests passing
> - Fedora X86_64 - all tests passing
> - OpenSUSE Leap X86_64 - all tests passing
> - OpenSUSE tw X86_64 - all tests passing
> - Rawhide X86_64 - all tests passing
> - macos x86_64 - all tests passing
> - Debian ppc64 - some tests failing
> - Fedora ppc64le - some tests failing
> - Fedora s390x - some tests failing
>
> The patch set is as follows:
>
> [PATCH Rust front-end v2 01/37] Use DW_ATE_UTF for the Rust 'char'
> [PATCH Rust front-end v2 02/37] gccrs: Add nessecary hooks for a Rust
> [PATCH Rust front-end v2 03/37] gccrs: Add Debug info testsuite
> [PATCH Rust front-end v2 04/37] gccrs: Add link cases testsuite
> [PATCH Rust front-end v2 05/37] gccrs: Add general compilation test
> [PATCH Rust front-end v2 06/37] gccrs: Add execution test cases
> [PATCH Rust front-end v2 07/37] gccrs: Add gcc-check-target
> [PATCH Rust front-end v2 08/37] gccrs: Add the Rust front-end AST
> [PATCH Rust front-end v2 09/37] gccrs: Add Lexer for Rust front-end
> [PATCH Rust front-end v2 10/37] gccrs: Add Parser for Rust front-end
> [PATCH Rust front-end v2 11/37] gccrs: Add expansion pass for the
> [PATCH Rust front-end v2 12/37] gccrs: Add name resolution pass to
> [PATCH Rust front-end v2 13/37] gccrs: Add second intermedite
> [PATCH Rust front-end v2 14/37] gccrs: Add AST to HIR lowering pass
> [PATCH Rust front-end v2 15/37] gccrs: Add wrapper for make_unique
> [PATCH Rust front-end v2 16/37] gccrs: Add port of FNV hash used
> [PATCH Rust front-end v2 17/37] gccrs: Add Rust ABI enum helpers
> [PATCH Rust front-end v2 18/37] gccrs: Add Base62 implementation
> [PATCH Rust front-end v2 19/37] gccrs: Add implementation of Optional
> [PATCH Rust front-end v2 20/37] gccrs: Add attributes checker
> [PATCH Rust front-end v2 21/37] gccrs: Add helpers mappings canonical
> [PATCH Rust front-end v2 22/37] gccrs: Add type resolution and trait
> [PATCH Rust front-end v2 23/37] gccrs: Add unsafe checks for Rust
> [PATCH Rust front-end v2 24/37] gccrs: Add const checker
> [PATCH Rust front-end v2 25/37] gccrs: Add privacy checks
> [PATCH Rust front-end v2 26/37] gccrs: Add dead code scan on HIR
> [PATCH Rust front-end v2 27/37] gccrs: Add unused variable scan
> [PATCH Rust front-end v2 28/37] gccrs: Add metadata ouptput pass
> [PATCH Rust front-end v2 29/37] gccrs: HIR to GCC GENERIC lowering
> [PATCH Rust front-end v2 30/37] gccrs: These are wrappers ported from
> [PATCH Rust front-end v2 31/37] gccrs: Add GCC Rust front-end
> [PATCH Rust front-end v2 32/37] gccrs: Add config-lang.in
> [PATCH Rust front-end v2 33/37] gccrs: add lang-spec.h
> [PATCH Rust front-end v2 34/37] gccrs: add lang.opt
> [PATCH Rust front-end v2 35/37] gccrs: add compiler driver
> [PATCH Rust front-end v2 36/37] gccrs: compiler proper interface
> [PATCH Rust front-end v2 37/37] gccrs: Add README, CONTRIBUTING and
>
> --
> 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: Rust frontend patches v2

[Philip Herron]

Hi Martin

4.0K0001-Use-DW_ATE_UTF-for-the-Rust-char-type.patch
8.0K0002-gccrs-Add-nessecary-hooks-for-a-Rust-front-end-tests.patch
8.0K0003-gccrs-Add-Debug-info-testsuite.patch
12K 0004-gccrs-Add-link-cases-testsuite.patch
356K0005-gccrs-Add-general-compilation-test-cases.patch
132K0006-gccrs-Add-execution-test-cases.patch
4.0K0007-gccrs-Add-gcc-check-target-check-rust.patch
656K0008-gccrs-Add-the-Rust-front-end-AST-data-structures.patch
112K0009-gccrs-Add-Lexer-for-Rust-front-end.patch
504K0010-gccrs-Add-Parser-for-Rust-front-end.patch
200K0011-gccrs-Add-expansion-pass-for-the-Rust-front-end.patch
204K0012-gccrs-Add-name-resolution-pass-to-the-Rust-front-end.patch
476K0013-gccrs-Add-second-intermedite-representation-called-H.patch
212K0014-gccrs-Add-AST-to-HIR-lowering-pass.patch
4.0K0015-gccrs-Add-wrapper-for-make_unique.patch
4.0K0016-gccrs-Add-port-of-FNV-hash-used-during-legacy-symbol.patch
4.0K0017-gccrs-Add-Rust-ABI-enum-helpers.patch
4.0K0018-gccrs-Add-Base62-implementation.patch
12K 0019-gccrs-Add-implementation-of-Optional.patch
28K 0020-gccrs-Add-attributes-checker.patch
60K 0021-gccrs-Add-helpers-mappings-canonical-path-and-lang-i.patch
628K0022-gccrs-Add-type-resolution-and-trait-solving-pass.patch
32K 0023-gccrs-Add-unsafe-checks-for-Rust.patch
28K 0024-gccrs-Add-const-checker.patch
72K 0025-gccrs-Add-privacy-checks.patch
24K 0026-gccrs-Add-dead-code-scan-on-HIR.patch
8.0K0027-gccrs-Add-unused-variable-scan.patch
76K 0028-gccrs-Add-metadata-ouptput-pass.patch
460K0029-gccrs-HIR-to-GCC-GENERIC-lowering.patch
36K 0030-gccrs-These-are-wrappers-ported-from-reusing-gccgo.patch
16K 0031-gccrs-Add-GCC-Rust-front-end-Make-lang.in.patch
4.0K0032-gccrs-Add-config-lang.in.patch
4.0K0033-gccrs-add-lang-spec.h.patch
8.0K0034-gccrs-add-lang.opt.patch
8.0K0035-gccrs-add-compiler-driver.patch
64K 0036-gccrs-compiler-proper-interface-kicks-off-the-pipeli.patch
104K0037-gccrs-Add-README-CONTRIBUTING-and-compiler-logo.patch

I hope this helps. I can do another pass at splitting up on these
patches if it will help.

--Phil

On Thu, 25 Aug 2022 at 10:52, Martin Liška  wrote:
>
> On 8/25/22 11:46, Philip Herron wrote:
> > The missing patches on
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-August/thread.html#600200
> > are 8, 10, 13, 29, and 22.
>
> Hmm, I think our limit is pretty low, sorry for that.
>
> Can you please paste output of du -hs 00*?
>
> What about limit increase, how much space do we have on sourceware 
> infrastructure?
>
> Thanks,
> Martin
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Rust frontend patches v2

[Philip Herron]

On Thu, 25 Aug 2022 at 13:50, Frank Ch. Eigler  wrote:
>
> Hi -
>
>
> > 12K 0004-gccrs-Add-link-cases-testsuite.patch
> > 356K0005-gccrs-Add-general-compilation-test-cases.patch
> > 132K0006-gccrs-Add-execution-test-cases.patch
> > 4.0K0007-gccrs-Add-gcc-check-target-check-rust.patch
> > 656K0008-gccrs-Add-the-Rust-front-end-AST-data-structures.patch
> > 112K0009-gccrs-Add-Lexer-for-Rust-front-end.patch
> > 504K0010-gccrs-Add-Parser-for-Rust-front-end.patch
> > 200K0011-gccrs-Add-expansion-pass-for-the-Rust-front-end.patch
> > 204K0012-gccrs-Add-name-resolution-pass-to-the-Rust-front-end.patch
> > 476K0013-gccrs-Add-second-intermedite-representation-called-H.patch
> > [...]
>
> Just curious whether a human reviewer expected to read through this
> much content?  If not, and if this structure is only for machine /
> bisecting purposes, maybe they're not worth also emailing.
>
> - FChE

That's a good point. I prefer reading this stuff on the git branch either:

https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master
https://github.com/Rust-GCC/gccrs

The first patch here is a nice isolated GCC change the rest of the
patches are either pure front-end code or setting up the rust target
for the test suite.

The main patches I think people will be interested in are:

[PATCH Rust front-end v2 01/37] Use DW_ATE_UTF for the Rust 'char'
[PATCH Rust front-end v2 07/37] gccrs: Add gcc-check-target
[PATCH Rust front-end v2 31/37] gccrs: Add GCC Rust front-end
[PATCH Rust front-end v2 32/37] gccrs: Add config-lang.in
[PATCH Rust front-end v2 33/37] gccrs: add lang-spec.h
[PATCH Rust front-end v2 34/37] gccrs: add lang.opt
[PATCH Rust front-end v2 35/37] gccrs: add compiler driver
[PATCH Rust front-end v2 36/37] gccrs: compiler proper interface

Eventually, when we clean it up, our port of the constexpr.cc from the
C++ front-end might be of interest to other front-ends.

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

Re: Sourceware accepted as SFC member project

[Philip Herron]

Hi Mark

Do you have the link available to join this mailing list? I am
interested to see how this goes, the SFC is a great organization. I
love the idea of it for gccrs but not sure how that would affect
interaction with GCC.

I hope you are doing well.

--Phil

On Thu, 8 Sept 2022 at 23:58, Mark Wielaard  wrote:
>
> Hi,
>
> We are very grateful for the public replies and suggestions received
> to our proposal, which were all very positive. And we are happy to
> report that the SFC's Evaluations Committee has voted to accept
> Sourceware as a Conservancy member project. If people are interested
> in, or want to help out with, the next steps they are invited to join
> the sourceware overseers list.
>
> https://sourceware.org/pipermail/overseers/2022q3/018834.html
>
> Thanks,
>
> Chris Faylor 
> Frank Eigler 
> Mark Wielaard 
> --
> 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: Rust front-end

[Philip Herron]

Hi everyone,

As the cut-off for merging is coming up in November, quite a few of
our patches have not been reviewed yet.

There are a few main issues that have been raised so far, and we are
fixing those at the moment in preparation for version 3 of the
patches. Is there anything else we can do to make reviewing the rest
of the patches easier?

Thanks

--Phil

On Mon, 11 Jul 2022 at 16:02, David Edelsohn  wrote:
>
> On Mon, Jun 27, 2022 at 10:52 AM Philip Herron
>  wrote:
> >
> > Hi everyone,
> >
> > Since November 2020, I've worked full-time on the Rust front-end for
> > GCC, thanks to Open Source Security, Inc and Embecosm. As a result, I
> > am writing to this mailing list to seek feedback from the collective
> > experience here early to plan a path for upstreaming the front-end
> > into GCC.
> >
> > 1. What is the actual process of merging a prominent feature like this 
> > upstream
> >   - How do we review this?
> >   - Do we create a "mega-commit" patch
> >   - How long should we expect this review process to take
> >   - Is there anything we can do to make this easier?
> >
> > 2. What sort of quality does the GCC community expect?
> >   - I think it is essential that we can compile valid test cases from
> > a testsuite and real projects before merging.
> >   - It seems reasonable that our error handling may not be 100% but be
> > expected to improve over time
> >   - Upon merging, can features like Rust be marked as experimental
> >
> > 3. How do GCC releases work?
> >   - If you miss a window can we still merge code into the front-end?
> >   - Can we merge without a borrow checker and backport this in the future?
> >
> > 4. What about the possibility of merging sooner rather than later,
> > which would help the project gain interest through the increased
> > visibility of it as part of the GCC family.
> >   - Does this still allow for development churn, or will it cause friction?
> >
> > 5. Does anyone have prior experience or advice they could give us?
> >
> > For some context, my current project plan brings us to November 2022
> > where we (unexpected events permitting) should be able to support
> > valid Rust code targeting Rustc version ~1.40 and reuse libcore,
> > liballoc and libstd. This date does not account for the borrow checker
> > feature and the proc macro crate, which we have a plan to implement,
> > but this will be a further six-month project.
> >
> > Regarding patch management, we currently do our development on GitHub:
> > https://github.com/Rust-GCC/gccrs; this means we can integrate our
> > issue tracking with the official Rust project by linking back to the
> > official Rust project's RFC issues, for example. The downside is that
> > when someone uses our compiler and hits an ICE, they will be directed
> > to the GCC Bugzilla, which is correct but can lead to a mismatch in
> > issue tracking. Nevertheless, I think it's essential to have the
> > GitHub link here to integrate with the broader Rust community. I
> > believe we can triage Rust issues on the Bugzilla and raise associated
> > ones on Github to manage this.
> >
> > From my perspective as the lead on this front-end, we are currently
> > under heavy development, so this means a fair amount of code churn
> > still, and I don't see this changing until we can successfully compile
> > the libcore crate later this year. Although I would love to see us
> > merged into GCC 13, I want to make sure this project is a success for
> > everyone, and this might mean pushing back to the next release window
> > to make sure this is manageable to produce a quality front-end to sit
> > alongside the others.
> >
> > I wish to thank you those in the GCC developer community, who have
> > inspired me and helped me navigate my journey to this point in time.
> >
> > - Thomas Schwinge
> > - Mark Wielaard
> > - Tom Tromey
> > - Ian Lance Taylor
> > - David Edelsohn
> > - David Malcolm
> > - Martin Jambor
>
> Congratulations! The GCC Steering Committee has voted to accept the
> contribution of the Rust Frontend (aka GCC Rust) to GCC.  Please work
> with the GCC Global Reviewers and GCC Release Managers for technical
> review and technical approval of the patches.  We look forward to
> including a preliminary, beta version of GCC Rust in GCC 13 as a
> non-default language.
>
> Thanks, David
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Rust front-end

[Philip Herron]

Hi David

We made a table to try and track this a bit better:

| Patch   |
Reviewed | Accepted |
|-+--+--|
| 0001-Use-DW_ATE_UTF-for-the-Rust-char-type.patch| x
  | x|
| 0002-gccrs-Add-nessecary-hooks-for-a-Rust-front-end-tests.patch | x
  | x|
| 0003-gccrs-Add-Debug-info-testsuite.patch   |
  |  |
| 0004-gccrs-Add-link-cases-testsuite.patch   |
  |  |
| 0005-gccrs-Add-general-compilation-test-cases.patch |
  |  |
| 0006-gccrs-Add-execution-test-cases.patch   |
  |  |
| 0007-gccrs-Add-gcc-check-target-check-rust.patch| x
  |  |
| 0008-gccrs-Add-the-Rust-front-end-AST-data-structures.patch |
  |  |
| 0009-gccrs-Add-Lexer-for-Rust-front-end.patch   | x
  |  |
| 0010-gccrs-Add-Parser-for-Rust-front-end.patch  |
  |  |
| 0011-gccrs-Add-expansion-pass-for-the-Rust-front-end.patch  |
  |  |
| 0012-gccrs-Add-name-resolution-pass-to-the-Rust-front-end.patch |
  |  |
| 0013-gccrs-Add-second-intermedite-representation-called-H.patch |
  |  |
| 0014-gccrs-Add-AST-to-HIR-lowering-pass.patch   |
  |  |
| 0015-gccrs-Add-wrapper-for-make_unique.patch|
  |  |
| 0016-gccrs-Add-port-of-FNV-hash-used-during-legacy-symbol.patch |
  |  |
| 0017-gccrs-Add-Rust-ABI-enum-helpers.patch  |
  |  |
| 0018-gccrs-Add-Base62-implementation.patch  |
  |  |
| 0019-gccrs-Add-implementation-of-Optional.patch |
  |  |
| 0020-gccrs-Add-attributes-checker.patch |
  |  |
| 0021-gccrs-Add-helpers-mappings-canonical-path-and-lang-i.patch |
  |  |
| 0022-gccrs-Add-type-resolution-and-trait-solving-pass.patch |
  |  |
| 0023-gccrs-Add-unsafe-checks-for-Rust.patch |
  |  |
| 0024-gccrs-Add-const-checker.patch  |
  |  |
| 0025-gccrs-Add-privacy-checks.patch |
  |  |
| 0026-gccrs-Add-dead-code-scan-on-HIR.patch  |
  |  |
| 0027-gccrs-Add-unused-variable-scan.patch   |
  |  |
| 0028-gccrs-Add-metadata-ouptput-pass.patch  |
  |  |
| 0029-gccrs-HIR-to-GCC-GENERIC-lowering.patch|
  |  |
| 0030-gccrs-These-are-wrappers-ported-from-reusing-gccgo.patch   |
  |  |
| 0031-gccrs-Add-GCC-Rust-front-end-Make-lang.in.patch| x
  |  |
| 0032-gccrs-Add-config-lang.in.patch | x
  | x|
| 0033-gccrs-add-lang-spec.h.patch|
  |  |
| 0034-gccrs-add-lang.opt.patch   | x
  |  |
| 0035-gccrs-add-compiler-driver.patch|
  |  |
| 0036-gccrs-compiler-proper-interface-kicks-off-the-pipeli.patch |
  |  |
| 0037-gccrs-Add-README-CONTRIBUTING-and-compiler-logo.patch  |
  |  |

I think the formatting from org-mode didn't come through 100%, but it
looks readable enough. The patches which are reviewed but not accepted
have issues which we have fixed locally in preparation for sending
version 3 of the patches. I also found using this link made it much
easier to see which patches have had reviews and which have not:

https://inbox.sourceware.org/gcc-patches/20220824115956.737931-9-philip.her...@embecosm.com/T/#rbff0bb3df2780fecd9ee3d2baa864d9140d24b54

You can easily see the thread of patches and those which have
responses and which have not.

Thanks

--Phil

On Tue, 4 Oct 2022 at 13:43, David Malcolm  wrote:
>
> On Tue, 2022-10-04 at 13:29 +0100, Philip Herron wrote:
> > Hi everyone,
> >
> > As the cut-off for merging is coming up in November, quite a few of
> > our patches have not been reviewed yet.
> >
> > There are a few main issues that have been raised so far, and we are
> > fixing those at the moment in preparation for version 3 of the
> > patches. Is there anything else we can do to make reviewing the rest
> > of the patches easier?
>
> Do you have a list of which patches need reviewing?
> e.g. perhaps a page showing:
> - which patches are waiting for a reviewer, as opposed to
> - which patches are already approved
> - which patches have issues identified in review
>   - ...where no-one is yet working on addressing them
>   - ...where someone is working on addressing them
>

Re: Rust front-end

[Philip Herron]

Hi Jakub,

Thanks for this, as I mentioned in my response to David we have made a
table and use this link to try and see what's going on
https://inbox.sourceware.org/gcc-patches/20220824115956.737931-9-philip.her...@embecosm.com/T/#rbff0bb3df2780fecd9ee3d2baa864d9140d24b54

Do you think I should send a PING email to each patch which we are
waiting on review for?

Thanks

--Phil

On Tue, 4 Oct 2022 at 14:04, Jakub Jelinek  wrote:
>
> On Tue, Oct 04, 2022 at 08:42:58AM -0400, David Malcolm via Gcc wrote:
> > On Tue, 2022-10-04 at 13:29 +0100, Philip Herron wrote:
> > > Hi everyone,
> > >
> > > As the cut-off for merging is coming up in November, quite a few of
> > > our patches have not been reviewed yet.
> > >
> > > There are a few main issues that have been raised so far, and we are
> > > fixing those at the moment in preparation for version 3 of the
> > > patches. Is there anything else we can do to make reviewing the rest
> > > of the patches easier?
> >
> > Do you have a list of which patches need reviewing?
> > e.g. perhaps a page showing:
> > - which patches are waiting for a reviewer, as opposed to
> > - which patches are already approved
> > - which patches have issues identified in review
> >   - ...where no-one is yet working on addressing them
> >   - ...where someone is working on addressing them
> > etc
> >
> > to make it clearer what the next action is for each patch, and who is
> > meant to be taking it.
> >
> > (within Red Hat, we used to call this "who has the ball?")
>
> Yeah, our policy in https://gcc.gnu.org/contribute.html states that
> "Pinging patches, Getting patches applied
>
> If you do not receive a response to a patch that you have submitted within
> two weeks or so, it may be a good idea to chase it by sending a follow-up
> e-mail to the same list(s).  Patches can occasionally fall through the
> cracks.  Please be sure to include a brief summary of the patch and the URL
> of the entry in the mailing list archive of the original submission."
>
> If some patches have been already reviewed, others partly, others in the
> works and others need review, sending a mail with those details
> so that it is easy to find out what is still pending is appreciated even
> more.
>
> Jakub
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Invitation: GCC Rust Community Call October @ Fri 7 Oct 2022 10am - 10:30am (BST) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20221007T09Z
DTEND:20221007T093000Z
DTSTAMP:20221005T094748Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:0qcn29obl0m2n9imlh6eonk...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=philip.her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.herron@embecosm
 .com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=tho...@codesourcery.com;X-NUM-GUESTS=0:mailto:thomas@codesourcery.c
 om
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=gcc-rust@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=m...@klomp.org;X-NUM-GUESTS=0:mailto:m...@klomp.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=phil...@recogni.com;X-NUM-GUESTS=0:mailto:phil...@recogni.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=arthur.co...@embecosm.com;X-NUM-GUESTS=0:mailto:arthur.cohen@embeco
 sm.com
X-MICROSOFT-CDO-OWNERAPPTID:219226479
CREATED:20221005T094746Z
DESCRIPTION:Hi everyone\,It's been two months since our last commun
 ity call in August. Let us get the ball rolling again with one this Friday:
 Date/Time: 7th October 2022 at: 09h00 UTC  \;Fri\, Oct 7 2022\,
  10:00Mailing list: https://gcc.gnu.org/mailman/listinfo/gcc-r
 ust">https://gcc.gnu.org/mailman/listinfo/gcc-rustZulip: https://gcc-rust.zulipchat.com/IRC:
  irc.oftc.net #gccrustVideo Link: https://meet.jit.si/gccrs-co
 mmunity-call-october">https://meet.jit.si/gccrs-community-call-october<
 br>Agenda: https://hackmd.io/ULvMyAraR0C8jIVOfTPJcg";>https://hackm
 d.io/ULvMyAraR0C8jIVOfTPJcgIf this time does not suit\, we can 
 try again next week. Thanks--Phil
LAST-MODIFIED:20221005T094746Z
LOCATION:https://meet.jit.si/gccrs-community-call-october
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:GCC Rust Community Call October
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [GSoC] gccrs Unicode support

[Philip Herron via Gcc-rust]

Hi Raiki

Excellent work on getting up to speed on the rust front-end. From my
perspective I am interested to see what the wider GCC community thinks
about using https://www.gnu.org/software/libunistring/ library within GCC
instead of rolling our own, this means it will be another dependency on GCC.

The other option is there is already code in the other front-ends to do
this so in the worst case it should be possible to extract something out of
them and possibly make this a shared piece of functionality which we can
mentor you through.

Thanks

--Phil

On Mon, 13 Mar 2023 at 16:19, Raiki Tamura via Gcc  wrote:

> Hello,
>
> My name is Raiki Tamura, an undergraduate student at Kyoto University in
> Japan and I want to work on Unicode support in gccrs this year.
> I have already written my proposal (linked below) and shared it with the
> gccrs team in Zulip.
> In the project, I am planning to use the GNU unistring library to handle
> Unicode characters and the GNU IDN library to normalize identifiers.
> According to my potential mentor, it would provide Unicode libraries for
> all frontends in GCC. If there are concerns or feedback about this, please
> tell me about it.
> Thank you.
>
> Link to my proposal:
>
> https://docs.google.com/document/d/1MgsbJMF-p-ndgrX2iKeWDR5KPSWw9Z7onsHIiZ2pPKs/edit?usp=sharing
>
> Raiki Tamura
>
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust