Re: Rust frontend patches v3
Hi Richard, On 11/10/22 11:52, Richard Biener wrote: On Wed, Oct 26, 2022 at 10:16 AM wrote: This is the fixed version of our previous patch set for gccrs - We've adressed the comments raised in our previous emails. This patch set does not contain any work that was not previously included, such as closure support, the constant evaluator port, or the better implementation of target hooks by Iain Buclaw. They will follow up in subsequent patch sets. Thanks again to Open Source Security, inc and Embecosm who have accompanied us for this work. Many thanks to all of the contributors and our community, who made this possible. A very special thanks to Philip Herron, without whose mentoring I would have never been in a position to send these patches. You can see the current status of our work on our branch: https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master The patch set contains the following: Can you mark the patches that have been reviewed/approved? Can you maybe either split the series or organize it in a way to separate the pieces touching common parts of GCC from the gcc/rust/ parts? Can you separate testsuite infrastructure from actual tests, can you mark/separate target specific changes? And for those (then small) changes CC the appropriate maintainers? Thanks a lot for all the feedback. I'll apply the required changes and make sure the patchset(s) are a bit easier to review. All the best, Arthur Thanks, Richard. [PATCH Rust front-end v3 01/46] Use DW_ATE_UTF for the Rust 'char' [PATCH Rust front-end v3 02/46] gccrs: Add nessecary hooks for a Rust [PATCH Rust front-end v3 03/46] gccrs: Add Debug info testsuite [PATCH Rust front-end v3 04/46] gccrs: Add link cases testsuite [PATCH Rust front-end v3 05/46] gccrs: Add general compilation test [PATCH Rust front-end v3 06/46] gccrs: Add execution test cases [PATCH Rust front-end v3 07/46] gccrs: Add gcc-check-target [PATCH Rust front-end v3 08/46] gccrs: Add Rust front-end base AST [PATCH Rust front-end v3 09/46] gccrs: Add definitions of Rust Items [PATCH Rust front-end v3 10/46] gccrs: Add full definitions of Rust [PATCH Rust front-end v3 11/46] gccrs: Add Rust AST visitors [PATCH Rust front-end v3 12/46] gccrs: Add Lexer for Rust front-end [PATCH Rust front-end v3 13/46] gccrs: Add Parser for Rust front-end [PATCH Rust front-end v3 14/46] gccrs: Add Parser for Rust front-end [PATCH Rust front-end v3 15/46] gccrs: Add expansion pass for the [PATCH Rust front-end v3 16/46] gccrs: Add name resolution pass to [PATCH Rust front-end v3 17/46] gccrs: Add declarations for Rust HIR [PATCH Rust front-end v3 18/46] gccrs: Add HIR definitions and [PATCH Rust front-end v3 19/46] gccrs: Add AST to HIR lowering pass [PATCH Rust front-end v3 20/46] gccrs: Add wrapper for make_unique [PATCH Rust front-end v3 21/46] gccrs: Add port of FNV hash used [PATCH Rust front-end v3 22/46] gccrs: Add Rust ABI enum helpers [PATCH Rust front-end v3 23/46] gccrs: Add Base62 implementation [PATCH Rust front-end v3 24/46] gccrs: Add implementation of Optional [PATCH Rust front-end v3 25/46] gccrs: Add attributes checker [PATCH Rust front-end v3 26/46] gccrs: Add helpers mappings canonical [PATCH Rust front-end v3 27/46] gccrs: Add type resolution and trait [PATCH Rust front-end v3 28/46] gccrs: Add Rust type information [PATCH Rust front-end v3 29/46] gccrs: Add remaining type system [PATCH Rust front-end v3 30/46] gccrs: Add unsafe checks for Rust [PATCH Rust front-end v3 31/46] gccrs: Add const checker [PATCH Rust front-end v3 32/46] gccrs: Add privacy checks [PATCH Rust front-end v3 33/46] gccrs: Add dead code scan on HIR [PATCH Rust front-end v3 34/46] gccrs: Add unused variable scan [PATCH Rust front-end v3 35/46] gccrs: Add metadata ouptput pass [PATCH Rust front-end v3 36/46] gccrs: Add base for HIR to GCC [PATCH Rust front-end v3 37/46] gccrs: Add HIR to GCC GENERIC [PATCH Rust front-end v3 38/46] gccrs: Add HIR to GCC GENERIC [PATCH Rust front-end v3 39/46] gccrs: These are wrappers ported from [PATCH Rust front-end v3 40/46] gccrs: Add GCC Rust front-end [PATCH Rust front-end v3 41/46] gccrs: Add config-lang.in [PATCH Rust front-end v3 42/46] gccrs: Add lang-spec.h [PATCH Rust front-end v3 43/46] gccrs: Add lang.opt [PATCH Rust front-end v3 44/46] gccrs: Add compiler driver [PATCH Rust front-end v3 45/46] gccrs: Compiler proper interface [PATCH Rust front-end v3 46/46] gccrs: Add README, CONTRIBUTING and -- Arthur Cohen Toolchain Engineer Embecosm GmbH Geschäftsführer: Jeremy Bennett Niederlassung: Nürnberg Handelsregister: HR-B 36368 www.embecosm.de Fürther Str. 27 90429 Nürnberg Tel.: 091 - 128 707 040 Fax: 091 - 128 707 077 OpenPGP_0x1B3465B044AD9C65.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Rust frontend patches v3
On Wed, Oct 26, 2022 at 10:16 AM wrote: > > This is the fixed version of our previous patch set for gccrs - We've adressed > the comments raised in our previous emails. > > This patch set does not contain any work that was not previously included, > such > as closure support, the constant evaluator port, or the better implementation > of target hooks by Iain Buclaw. They will follow up in subsequent patch sets. > > Thanks again to Open Source Security, inc and Embecosm who have accompanied us > for this work. > > Many thanks to all of the contributors and our community, who made this > possible. > > A very special thanks to Philip Herron, without whose mentoring I would have > never been in a position to send these patches. > > You can see the current status of our work on our branch: > https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master > > The patch set contains the following: Can you mark the patches that have been reviewed/approved? Can you maybe either split the series or organize it in a way to separate the pieces touching common parts of GCC from the gcc/rust/ parts? Can you separate testsuite infrastructure from actual tests, can you mark/separate target specific changes? And for those (then small) changes CC the appropriate maintainers? Thanks, Richard. > [PATCH Rust front-end v3 01/46] Use DW_ATE_UTF for the Rust 'char' > [PATCH Rust front-end v3 02/46] gccrs: Add nessecary hooks for a Rust > [PATCH Rust front-end v3 03/46] gccrs: Add Debug info testsuite > [PATCH Rust front-end v3 04/46] gccrs: Add link cases testsuite > [PATCH Rust front-end v3 05/46] gccrs: Add general compilation test > [PATCH Rust front-end v3 06/46] gccrs: Add execution test cases > [PATCH Rust front-end v3 07/46] gccrs: Add gcc-check-target > [PATCH Rust front-end v3 08/46] gccrs: Add Rust front-end base AST > [PATCH Rust front-end v3 09/46] gccrs: Add definitions of Rust Items > [PATCH Rust front-end v3 10/46] gccrs: Add full definitions of Rust > [PATCH Rust front-end v3 11/46] gccrs: Add Rust AST visitors > [PATCH Rust front-end v3 12/46] gccrs: Add Lexer for Rust front-end > [PATCH Rust front-end v3 13/46] gccrs: Add Parser for Rust front-end > [PATCH Rust front-end v3 14/46] gccrs: Add Parser for Rust front-end > [PATCH Rust front-end v3 15/46] gccrs: Add expansion pass for the > [PATCH Rust front-end v3 16/46] gccrs: Add name resolution pass to > [PATCH Rust front-end v3 17/46] gccrs: Add declarations for Rust HIR > [PATCH Rust front-end v3 18/46] gccrs: Add HIR definitions and > [PATCH Rust front-end v3 19/46] gccrs: Add AST to HIR lowering pass > [PATCH Rust front-end v3 20/46] gccrs: Add wrapper for make_unique > [PATCH Rust front-end v3 21/46] gccrs: Add port of FNV hash used > [PATCH Rust front-end v3 22/46] gccrs: Add Rust ABI enum helpers > [PATCH Rust front-end v3 23/46] gccrs: Add Base62 implementation > [PATCH Rust front-end v3 24/46] gccrs: Add implementation of Optional > [PATCH Rust front-end v3 25/46] gccrs: Add attributes checker > [PATCH Rust front-end v3 26/46] gccrs: Add helpers mappings canonical > [PATCH Rust front-end v3 27/46] gccrs: Add type resolution and trait > [PATCH Rust front-end v3 28/46] gccrs: Add Rust type information > [PATCH Rust front-end v3 29/46] gccrs: Add remaining type system > [PATCH Rust front-end v3 30/46] gccrs: Add unsafe checks for Rust > [PATCH Rust front-end v3 31/46] gccrs: Add const checker > [PATCH Rust front-end v3 32/46] gccrs: Add privacy checks > [PATCH Rust front-end v3 33/46] gccrs: Add dead code scan on HIR > [PATCH Rust front-end v3 34/46] gccrs: Add unused variable scan > [PATCH Rust front-end v3 35/46] gccrs: Add metadata ouptput pass > [PATCH Rust front-end v3 36/46] gccrs: Add base for HIR to GCC > [PATCH Rust front-end v3 37/46] gccrs: Add HIR to GCC GENERIC > [PATCH Rust front-end v3 38/46] gccrs: Add HIR to GCC GENERIC > [PATCH Rust front-end v3 39/46] gccrs: These are wrappers ported from > [PATCH Rust front-end v3 40/46] gccrs: Add GCC Rust front-end > [PATCH Rust front-end v3 41/46] gccrs: Add config-lang.in > [PATCH Rust front-end v3 42/46] gccrs: Add lang-spec.h > [PATCH Rust front-end v3 43/46] gccrs: Add lang.opt > [PATCH Rust front-end v3 44/46] gccrs: Add compiler driver > [PATCH Rust front-end v3 45/46] gccrs: Compiler proper interface > [PATCH Rust front-end v3 46/46] gccrs: Add README, CONTRIBUTING and >
Re: Rust frontend patches v3
On Fri, 2022-10-28 at 17:20 +0200, Arthur Cohen wrote: > > > On 10/28/22 15:06, David Malcolm wrote: > > On Fri, 2022-10-28 at 13:48 +0200, Arthur Cohen wrote: > > > Hi David, > > > > > > On 10/26/22 23:15, David Malcolm wrote: > > > > On Wed, 2022-10-26 at 10:17 +0200, > > > > arthur.co...@embecosm.com wrote: > > > > > This is the fixed version of our previous patch set for gccrs > > > > > - > > > > > We've > > > > > adressed > > > > > the comments raised in our previous emails. [...snip...] > > > > I'm guessing that almost all of gccrs testing so far has been on > > relatively small examples, so that even if the GC considers > > collecting, > > the memory usage might not have exceeded the threshold for actually > > doing the mark-and-sweep collection, and so no collection has been > > happening during your testing. > > > > In case you haven't tried yet, you might want to try adding: > > --param=ggc-min-expand=0 --param=ggc-min-heapsize=0 > > which IIRC forces the GC to actually do its mark-and-sweep > > collection > > at every potential point where it might collect. > > That's very helpful, thanks a lot. I've ran our testsuite with these > and > found no issues, but we might consider adding that to our CI setup to > make sure. Great! Though as noted, for libgccjit it slows the testsuite down *massively*, so you might want to bear that in mind. I'm doing it for libgccjit because libgccjit looks like a "frontend" to the rest of the GCC codebase, but it's a deeply weird one, and so tends to uncover weird issues :-/ Dave > > Kindly, > > Arthur > > > I use these params in libgccjit's test suite; it massively slows > > things > > down, but it makes any GC misuse crash immediately even on minimal > > test > > cases, rather than hiding problems until you have a big (and thus > > nasty) test case. > > > > Hope this is helpful > > Dave > > > > > > > > > > > Hope this is constructive > > > > Dave > > > > > > > > > > Thanks a lot for the input, > > > > > > All the best, > > > > > > Arthur > > > > > > > > > > > > > >
Re: Rust frontend patches v3
On 10/28/22 15:06, David Malcolm wrote: On Fri, 2022-10-28 at 13:48 +0200, Arthur Cohen wrote: Hi David, On 10/26/22 23:15, David Malcolm wrote: On Wed, 2022-10-26 at 10:17 +0200, arthur.co...@embecosm.com wrote: This is the fixed version of our previous patch set for gccrs - We've adressed the comments raised in our previous emails. [...snip...] (Caveat: I'm not a global reviewer) Sorry if this is answered in the docs in the patch kit, but a high- level question: what's the interaction between gccrs and gcc's garbage collector? Are the only GC-managed objects (such as trees) either (a) created near the end of the gccrs, or (b) common globals created at initialization and with GTY roots? We only create trees at the last point of our compilation pipeline, before directly writing them to the backend. This then calls a `write_global_definitions` method, that we ported over directly from the Go frontend. Among other things, this method has the role of preserving trees from the GC using `go_preserve_from_gc()` (or `rust_preserve_from_gc()` in our case). Elsewhere in our pipeline, we never call any garbage-collection routines or GC-related functions. Are there any points where a collection happen within gccrs? Or is almost everything stored using gccrs's own data structures, and are these managed in the regular (non- GC) heap? This is correct. We have an AST representation, implemented using unique pointers, which is then lowered to an HIR, also using unique pointers. I skimmed the patches and see that gccrs uses e.g. std::vector, std::unique_ptr, std::map, and std::string; this seems reasonable to me, but it got me thinking about memory management strategies. I see various std::map e.g. in Rust::Compile::Context; so e.g. is the GC guaranteed never to collect whilst this is live? This is a really interesting question, and I hope the answer is yes! But I'm unsure as to how to enforce that, as I am not too familiar with the GCC GC. I'm hoping someone else will weigh in. As I said, we do not do anything particular with the GC during the execution of our `CompileCrate` visitor, so hopefully it shouldn't run. I'm guessing that almost all of gccrs testing so far has been on relatively small examples, so that even if the GC considers collecting, the memory usage might not have exceeded the threshold for actually doing the mark-and-sweep collection, and so no collection has been happening during your testing. In case you haven't tried yet, you might want to try adding: --param=ggc-min-expand=0 --param=ggc-min-heapsize=0 which IIRC forces the GC to actually do its mark-and-sweep collection at every potential point where it might collect. That's very helpful, thanks a lot. I've ran our testsuite with these and found no issues, but we might consider adding that to our CI setup to make sure. Kindly, Arthur I use these params in libgccjit's test suite; it massively slows things down, but it makes any GC misuse crash immediately even on minimal test cases, rather than hiding problems until you have a big (and thus nasty) test case. Hope this is helpful Dave Hope this is constructive Dave Thanks a lot for the input, All the best, Arthur OpenPGP_0x1B3465B044AD9C65.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Rust frontend patches v3
On Fri, 2022-10-28 at 13:48 +0200, Arthur Cohen wrote: > Hi David, > > On 10/26/22 23:15, David Malcolm wrote: > > On Wed, 2022-10-26 at 10:17 +0200, arthur.co...@embecosm.com wrote: > > > This is the fixed version of our previous patch set for gccrs - > > > We've > > > adressed > > > the comments raised in our previous emails. > > > > [...snip...] > > > > (Caveat: I'm not a global reviewer) > > > > Sorry if this is answered in the docs in the patch kit, but a high- > > level question: what's the interaction between gccrs and gcc's > > garbage > > collector? Are the only GC-managed objects (such as trees) either > > (a) > > created near the end of the gccrs, or (b) common globals created at > > initialization and with GTY roots? > > We only create trees at the last point of our compilation pipeline, > before directly writing them to the backend. This then calls a > `write_global_definitions` method, that we ported over directly from > the > Go frontend. Among other things, this method has the role of > preserving > trees from the GC using `go_preserve_from_gc()` (or > `rust_preserve_from_gc()` in our case). > > Elsewhere in our pipeline, we never call any garbage-collection > routines > or GC-related functions. > > > Are there any points where a collection happen within gccrs? Or is > > almost everything stored using > > gccrs's own data structures, and are these managed in the regular > > (non- > > GC) heap? > > This is correct. We have an AST representation, implemented using > unique > pointers, which is then lowered to an HIR, also using unique > pointers. > > > I skimmed the patches and see that gccrs uses e.g. std::vector, > > std::unique_ptr, std::map, and std::string; this seems reasonable > > to > > me, but it got me thinking about memory management strategies. > > > > I see various std::map e.g. in Rust::Compile::Context; so > > e.g. > > is the GC guaranteed never to collect whilst this is live? > > This is a really interesting question, and I hope the answer is yes! > But > I'm unsure as to how to enforce that, as I am not too familiar with > the > GCC GC. I'm hoping someone else will weigh in. As I said, we do not > do > anything particular with the GC during the execution of our > `CompileCrate` visitor, so hopefully it shouldn't run. I'm guessing that almost all of gccrs testing so far has been on relatively small examples, so that even if the GC considers collecting, the memory usage might not have exceeded the threshold for actually doing the mark-and-sweep collection, and so no collection has been happening during your testing. In case you haven't tried yet, you might want to try adding: --param=ggc-min-expand=0 --param=ggc-min-heapsize=0 which IIRC forces the GC to actually do its mark-and-sweep collection at every potential point where it might collect. I use these params in libgccjit's test suite; it massively slows things down, but it makes any GC misuse crash immediately even on minimal test cases, rather than hiding problems until you have a big (and thus nasty) test case. Hope this is helpful Dave > > > Hope this is constructive > > Dave > > > > Thanks a lot for the input, > > All the best, > > Arthur > > > >
Re: Rust frontend patches v3
On Fri, Oct 28, 2022 at 1:45 PM Arthur Cohen wrote: > > Hi David, > > On 10/26/22 23:15, David Malcolm wrote: > > On Wed, 2022-10-26 at 10:17 +0200, arthur.co...@embecosm.com wrote: > >> This is the fixed version of our previous patch set for gccrs - We've > >> adressed > >> the comments raised in our previous emails. > > > > [...snip...] > > > > (Caveat: I'm not a global reviewer) > > > > Sorry if this is answered in the docs in the patch kit, but a high- > > level question: what's the interaction between gccrs and gcc's garbage > > collector? Are the only GC-managed objects (such as trees) either (a) > > created near the end of the gccrs, or (b) common globals created at > > initialization and with GTY roots? > > We only create trees at the last point of our compilation pipeline, > before directly writing them to the backend. This then calls a > `write_global_definitions` method, that we ported over directly from the > Go frontend. Among other things, this method has the role of preserving > trees from the GC using `go_preserve_from_gc()` (or > `rust_preserve_from_gc()` in our case). > > Elsewhere in our pipeline, we never call any garbage-collection routines > or GC-related functions. > > > Are there any points where a collection happen within gccrs? Or is almost > > everything stored using > > gccrs's own data structures, and are these managed in the regular (non- > > GC) heap? > > This is correct. We have an AST representation, implemented using unique > pointers, which is then lowered to an HIR, also using unique pointers. > > > I skimmed the patches and see that gccrs uses e.g. std::vector, > > std::unique_ptr, std::map, and std::string; this seems reasonable to > > me, but it got me thinking about memory management strategies. > > > > I see various std::map e.g. in Rust::Compile::Context; so e.g. > > is the GC guaranteed never to collect whilst this is live? > > This is a really interesting question, and I hope the answer is yes! But > I'm unsure as to how to enforce that, as I am not too familiar with the > GCC GC. I'm hoping someone else will weigh in. As I said, we do not do > anything particular with the GC during the execution of our > `CompileCrate` visitor, so hopefully it shouldn't run. collection points are explicit, but some might be hidden behind middle-end APIs, in particular once you call cgraph::finalize_compilation_unit you should probably expect collection. Richard. > > Hope this is constructive > > Dave > > > > Thanks a lot for the input, > > All the best, > > Arthur > > > >
Re: Rust frontend patches v3
Hi David, On 10/26/22 23:15, David Malcolm wrote: On Wed, 2022-10-26 at 10:17 +0200, arthur.co...@embecosm.com wrote: This is the fixed version of our previous patch set for gccrs - We've adressed the comments raised in our previous emails. [...snip...] (Caveat: I'm not a global reviewer) Sorry if this is answered in the docs in the patch kit, but a high- level question: what's the interaction between gccrs and gcc's garbage collector? Are the only GC-managed objects (such as trees) either (a) created near the end of the gccrs, or (b) common globals created at initialization and with GTY roots? We only create trees at the last point of our compilation pipeline, before directly writing them to the backend. This then calls a `write_global_definitions` method, that we ported over directly from the Go frontend. Among other things, this method has the role of preserving trees from the GC using `go_preserve_from_gc()` (or `rust_preserve_from_gc()` in our case). Elsewhere in our pipeline, we never call any garbage-collection routines or GC-related functions. Are there any points where a collection happen within gccrs? Or is almost everything stored using gccrs's own data structures, and are these managed in the regular (non- GC) heap? This is correct. We have an AST representation, implemented using unique pointers, which is then lowered to an HIR, also using unique pointers. I skimmed the patches and see that gccrs uses e.g. std::vector, std::unique_ptr, std::map, and std::string; this seems reasonable to me, but it got me thinking about memory management strategies. I see various std::map e.g. in Rust::Compile::Context; so e.g. is the GC guaranteed never to collect whilst this is live? This is a really interesting question, and I hope the answer is yes! But I'm unsure as to how to enforce that, as I am not too familiar with the GCC GC. I'm hoping someone else will weigh in. As I said, we do not do anything particular with the GC during the execution of our `CompileCrate` visitor, so hopefully it shouldn't run. Hope this is constructive Dave Thanks a lot for the input, All the best, Arthur OpenPGP_0x1B3465B044AD9C65.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Rust frontend patches v3
On Wed, 2022-10-26 at 10:17 +0200, arthur.co...@embecosm.com wrote: > This is the fixed version of our previous patch set for gccrs - We've > adressed > the comments raised in our previous emails. [...snip...] (Caveat: I'm not a global reviewer) Sorry if this is answered in the docs in the patch kit, but a high- level question: what's the interaction between gccrs and gcc's garbage collector? Are the only GC-managed objects (such as trees) either (a) created near the end of the gccrs, or (b) common globals created at initialization and with GTY roots? Are there any points where a collection happen within gccrs? Or is almost everything stored using gccrs's own data structures, and are these managed in the regular (non- GC) heap? I skimmed the patches and see that gccrs uses e.g. std::vector, std::unique_ptr, std::map, and std::string; this seems reasonable to me, but it got me thinking about memory management strategies. I see various std::map e.g. in Rust::Compile::Context; so e.g. is the GC guaranteed never to collect whilst this is live? Hope this is constructive Dave
Rust frontend patches v3
This is the fixed version of our previous patch set for gccrs - We've adressed the comments raised in our previous emails. This patch set does not contain any work that was not previously included, such as closure support, the constant evaluator port, or the better implementation of target hooks by Iain Buclaw. They will follow up in subsequent patch sets. Thanks again to Open Source Security, inc and Embecosm who have accompanied us for this work. Many thanks to all of the contributors and our community, who made this possible. A very special thanks to Philip Herron, without whose mentoring I would have never been in a position to send these patches. You can see the current status of our work on our branch: https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master The patch set contains the following: [PATCH Rust front-end v3 01/46] Use DW_ATE_UTF for the Rust 'char' [PATCH Rust front-end v3 02/46] gccrs: Add nessecary hooks for a Rust [PATCH Rust front-end v3 03/46] gccrs: Add Debug info testsuite [PATCH Rust front-end v3 04/46] gccrs: Add link cases testsuite [PATCH Rust front-end v3 05/46] gccrs: Add general compilation test [PATCH Rust front-end v3 06/46] gccrs: Add execution test cases [PATCH Rust front-end v3 07/46] gccrs: Add gcc-check-target [PATCH Rust front-end v3 08/46] gccrs: Add Rust front-end base AST [PATCH Rust front-end v3 09/46] gccrs: Add definitions of Rust Items [PATCH Rust front-end v3 10/46] gccrs: Add full definitions of Rust [PATCH Rust front-end v3 11/46] gccrs: Add Rust AST visitors [PATCH Rust front-end v3 12/46] gccrs: Add Lexer for Rust front-end [PATCH Rust front-end v3 13/46] gccrs: Add Parser for Rust front-end [PATCH Rust front-end v3 14/46] gccrs: Add Parser for Rust front-end [PATCH Rust front-end v3 15/46] gccrs: Add expansion pass for the [PATCH Rust front-end v3 16/46] gccrs: Add name resolution pass to [PATCH Rust front-end v3 17/46] gccrs: Add declarations for Rust HIR [PATCH Rust front-end v3 18/46] gccrs: Add HIR definitions and [PATCH Rust front-end v3 19/46] gccrs: Add AST to HIR lowering pass [PATCH Rust front-end v3 20/46] gccrs: Add wrapper for make_unique [PATCH Rust front-end v3 21/46] gccrs: Add port of FNV hash used [PATCH Rust front-end v3 22/46] gccrs: Add Rust ABI enum helpers [PATCH Rust front-end v3 23/46] gccrs: Add Base62 implementation [PATCH Rust front-end v3 24/46] gccrs: Add implementation of Optional [PATCH Rust front-end v3 25/46] gccrs: Add attributes checker [PATCH Rust front-end v3 26/46] gccrs: Add helpers mappings canonical [PATCH Rust front-end v3 27/46] gccrs: Add type resolution and trait [PATCH Rust front-end v3 28/46] gccrs: Add Rust type information [PATCH Rust front-end v3 29/46] gccrs: Add remaining type system [PATCH Rust front-end v3 30/46] gccrs: Add unsafe checks for Rust [PATCH Rust front-end v3 31/46] gccrs: Add const checker [PATCH Rust front-end v3 32/46] gccrs: Add privacy checks [PATCH Rust front-end v3 33/46] gccrs: Add dead code scan on HIR [PATCH Rust front-end v3 34/46] gccrs: Add unused variable scan [PATCH Rust front-end v3 35/46] gccrs: Add metadata ouptput pass [PATCH Rust front-end v3 36/46] gccrs: Add base for HIR to GCC [PATCH Rust front-end v3 37/46] gccrs: Add HIR to GCC GENERIC [PATCH Rust front-end v3 38/46] gccrs: Add HIR to GCC GENERIC [PATCH Rust front-end v3 39/46] gccrs: These are wrappers ported from [PATCH Rust front-end v3 40/46] gccrs: Add GCC Rust front-end [PATCH Rust front-end v3 41/46] gccrs: Add config-lang.in [PATCH Rust front-end v3 42/46] gccrs: Add lang-spec.h [PATCH Rust front-end v3 43/46] gccrs: Add lang.opt [PATCH Rust front-end v3 44/46] gccrs: Add compiler driver [PATCH Rust front-end v3 45/46] gccrs: Compiler proper interface [PATCH Rust front-end v3 46/46] gccrs: Add README, CONTRIBUTING and
