Re: [GSoC] gccrs Unicode support

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

Re: [GSoC] gccrs Unicode support

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

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

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

Re: Rust front-end

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: >

Re: Rust front-end

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: >

Re: Rust front-end

...@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: > >

Re: Rust front-end

...@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: > >

Re: Rust front-end

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 R

Re: Rust front-end

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 R

Re: Sourceware accepted as SFC member project

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

Re: Rust frontend patches v2

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.0K

Re: Rust frontend patches v2

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.0K

Re: Rust frontend patches v2

-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-

Re: Rust frontend patches v2

-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-

Re: Rust frontend patches v2

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:

Re: Rust frontend patches v2

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:

Re: Rust frontend patches v1

Hi Martin, Not right now, it is on the to-do list, but do we have to do it in texinfo? Thanks --Phil On Wed, 24 Aug 2022 at 14:49, Martin Liška wrote: > > On 8/15/22 16:33, Martin Liška wrote: > > On 8/15/22 16:07, Manuel López-Ibáñez via Gcc-patches wrote: > >> Dear Philip, > >> > >> Another

Re: Rust frontend patches v1

hope this makes sense. Thanks --Phil On Thu, 28 Jul 2022 at 10:39, Philip Herron wrote: > > Thanks, for confirming David. I think it was too big in the end. I was > trying to figure out how to actually split that up but it seems > reasonable that I can split up the front-end patches

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

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

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)

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

Re: [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and x86_64

Schwinge wrote: > > Hi Phil! > > On 2022-07-28T11:51:37+0100, Philip Herron wrote: > > I think you are right here. There are parts in > > libstd/liballoc/libpanic which start to look for what CPU features are > > available iirc. > > Aha, good. That -- once we

Re: [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and x86_64

Hi Thomas, I think you are right here. There are parts in libstd/liballoc/libpanic which start to look for what CPU features are available iirc. Maintaining our patches here has been becoming difficult as of late, especially when it comes to libcore, which just cares about target pointer width

Re: Rust frontend patches v1

Thanks, for confirming David. I think it was too big in the end. I was trying to figure out how to actually split that up but it seems reasonable that I can split up the front-end patches into patches for each separate pass in the compiler seems like a reasonable approach for now. --Phil On Wed,

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

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

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

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

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

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

Re: Rust front-end

end 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, > > &

Re: Rust front-end

end 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, > > &

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

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

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

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

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

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

Rust front-end

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.

Rust front-end

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.

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

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

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

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

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

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

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

/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

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

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

Re: Regular Online GCC/Rust Meeting Time Slot

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

Re: Bad testcase

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

Bad testcase

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

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

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

Re: Buildbot failure in Wildebeest Builder on whole buildset

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

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

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

Re: qual_union_type help

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,

Re: qual_union_type help

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,

qual_union_type help

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} ; }

qual_union_type help

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} ; }

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

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

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

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

GCC Rust 2021

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

GCC Rust development Visualized

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

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

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

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

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

Re: Anything I can contribute?

Hi Kaisheng, There are plenty of places to get started on the Rust Front-end for GCC if you are interested? - https://github.com/Rust-GCC/gccrs - https://github.com/Rust-GCC/gccrs/blob/master/CONTRIBUTING.md - https://github.com/Rust-GCC/gccrs/issues?q=is%3Aissue+is%3Aopen+label%3Agood-first-pr

Monthly Community Meeting

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

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

021 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::st

Re: [PATCH] Fix raw byte string parsing of zero and out of range bytes

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 >

Re: Merge from GCC upstream into GCC/Rust

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?

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

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

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

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

Re: Cleanup some StructExpr related classes

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

Rust Compatibility

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

Re: Cleanup some StructExpr related classes

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 lo

Re: Cleanup some StructExpr related classes

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

GCC Rust community call

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:

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

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

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

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

Re: Buildbot failure in Wildebeest Builder on whole buildset

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 thi

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

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: >>

Re: [PATCH] More rustspec.cc cleanups

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.

Re: Modifying self

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 ( self) -> u32 > { > self.l -= 1; > self.l > } > } > > fn main () > { > let mut h = H { l: 11 };

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

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

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

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:gcc@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

Re: Using unsafe blocks in let expressions

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 >

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

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.

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

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. > --- >

Re: New contributor tasks

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

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

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

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

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 >

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

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. >

Re: GCC Rust Monthly Call - 2nd July 2021

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 havin

Re: GCC Rust Monthly Call - 2nd July 2021

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 havin

Re: Unit Type for Rust

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-

Re: Unit Type for Rust

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-

Unit Type for Rust

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

GCC Rust Monthly Call - 2nd July 2021

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):

GCC Rust Monthly Call - 2nd July 2021

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):

Re: tuple indexes

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

Re: tuple indexes

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 >> use

Re: tuple indexes

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

Re: Test results for gccrs on Debian unstable sh4

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

Re: GCC Rust monthly call

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/Report

Re: GCC Rust monthly call

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

Re: GCC Rust monthly call

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

Re: Test results for gccrs on Debian unstable aarch64

. --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

Re: Test results for gccrs on Debian unstable aarch64

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,

Re: GCC Rust monthly call

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/), whic

Re: GCC Rust monthly call

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/), whic

GCC Rust monthly call

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

  1   2   >