Re: GCC GSoC 2024: Call for project ideas and mentors
Hi Martin, On 1/15/24 18:48, Martin Jambor wrote: Hello, another year has passed, Google has announced there will be again Google Summer of Code (GsoC) in 2024 and the deadline for organizations to apply is already approaching (February 6th). I'd like to volunteer to be the main org-admin for GCC again but let me know if you think I shouldn't or that someone else should or if you want to do it instead. Otherwise I'll assume that I will and I hope that I can continue to rely on David Edelsohn and Thomas Schwinge to back me up and help me with some decision making along the way as my co-org-admins. I think that'd be good :) we've really appreciated all the work you've done for the past editions. We'll be discussing project ideas with the rest of the gccrs team and will update the page shortly. We'd love to mentor again this year. Thanks for getting in touch, Best, Arthur The most important bit: I would like to ask all (moderately) seasoned GCC contributors to consider mentoring a contributor this year and ideally also come up with a project that they would like to lead. I'm collecting proposal on our wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours to the top list there. Or, if you are unsure, post your offer and project idea as a reply here to the mailing list. Additionally, if you have added an idea to the list in the recent years, please review it whether it is still up-to-date or needs adjusting or should be removed altogether. = At this point, we need to collect list of project ideas. Eventually, each listed project idea should have: a) a project title, b) more detailed description of the project (2-5 sentences), c) expected outcomes (we do have a catch-almost-all formulation that outcome is generally patches at the bottom of the list on the wiki), d) skills required/preferred, e) project size - whether it is expected to take approximately 350, 175 or just 90 hours (the last option in new in 2024, see below), f) difficulty (easy, hard or medium, but we don't really have easy projects), and g) expected mentors. Project ideas that come without an offer to also mentor them are always fun to discuss, by all means feel free to reply to this email with yours and I will attempt to find a mentor, but please be aware that we can only use the suggestion it if we actually find one or ideally two. Everybody in the GCC community is invited to go over https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or otherwise bad project suggestions and help improve viable ones. Finally, please continue helping (prospective) students figure stuff out about GCC like you have always done in the past. As far as I know, GSoC 2024 should be quite similar to the last year, the most important parameters probably are these: - Contributors (formerly students) must either be full-time students or be "beginners to open source." - There are now three project sizes: roughly 90 hors (small), roughly 175 hours (medium-sized) and roughly 350 hours (large) of work in total. The small option is new this year but because our projects usually have a lengthy learning period, I think we will usually want to stick to the medium and large variants. - Timing should be pretty much as flexible as last year. The recommended "standard" duration is 12 weeks but depending on contributor's and mentor's needs and circumstances, projects can take anywhere between 10 and 22 weeks. There will be one mid-term and one final evaluation. For further details you can see: - The announcement of GSoC 2024: https://opensource.googleblog.com/2023/11/google-summer-of-code-2024-celebrating-20th-year.html - GSoC rules: https://summerofcode.withgoogle.com/rules - The detailed GSoC 2024 timeline: https://developers.google.com/open-source/gsoc/timeline - Elaborate project idea guidelines: https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list Thank you very much for your participation and help. Let's hope we attract some great contributors again this year. Martin -- 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.asc Description: OpenPGP digital signature
[Request for Comments] Using Rust libraries in the Rust frontend
Hi everyone, In order to increase the development speed of Rust features, we are seeking feedback on reusing some Rust components directly within our front-end. As mentioned in other conferences, the most important component we would like to integrate into the front-end is the polonius borrow-checker. Another component we've become interested in is the `rustc_format_parser` library, responsible for handling parsing and handling of format arguments as described in the documentation for `std::fmt` [1]. However, since these libraries are written in Rust, GCC in itself is not yet able to compile them. They all depend on the Rust standard library, which we cannot yet compile and link properly. This obviously raises a question - how to actually compile, integrate and distribute these components? We do have the option to rewrite them from scratch, but we feel that spending time on these existing, correct, battle-tested and easily integrable components instead of focusing on other aspects of the language would be a mistake. Spending this time instead on Rust features that we are missing for compiling these components would, in our opinion, yield more results, as it would also help in compiling other Rust programs. We could either distribute these components as compiled libraries, or look at integrating the official Rust compiler to our build system as a temporary measure. I am aware that this would mean restricting the Rust GCC front-end to platforms where the official Rust compiler is also available, which is less than ideal. However, this would only be temporary - as soon as the Rust front-end is able to compile these components, we would simply reuse them and compile them with gccrs as part of our bootstrapping process. The documentation for `std::fmt` [1] describes all of the features available in Rust format strings. It also contains a grammar for the format-string parser, which we would need to re-implement on top of supporting all the formatting features. As a prototype, I wrote an FFI interface to the `rustc_format_parser` library and integrated it to our macro expansion system, which took me less than a couple hours. In less than an afternoon, we had bindings for all of the exported types and functions in the library and had access to a compliant and performant Rust format string parser. But re-implementing a correct `format_args!()` parser - with the same performance as the Rust one, and the same amount of features - would probably take days, if not weeks. And we are talking about one of the simplest components we aim to reuse. Something like a fully-compliant trait solver for the Rust programming language would take months if not years to implement properly from scratch. I would like to stress once again that relying on distributing compiled libraries or using `rustc` in our build system would be temporary, and that these measures would be removed as soon as gccrs is able to compile these components from source. I am looking for comments on this decision as well as the best practices we could adopt. Have there been any similar decisions for other self-hosted front-ends? Any previous email threads/commits that you could point me to would be greatly appreciated. Thanks, Arthur [1]: https://doc.rust-lang.org/std/fmt/
Re: [Request for Comments] Using Rust libraries in the Rust frontend
Hi Richard, On 1/23/24 08:23, Richard Biener wrote: On Mon, Jan 22, 2024 at 7:51 PM Arthur Cohen wrote: Hi everyone, In order to increase the development speed of Rust features, we are seeking feedback on reusing some Rust components directly within our front-end. As mentioned in other conferences, the most important component we would like to integrate into the front-end is the polonius borrow-checker. Another component we've become interested in is the `rustc_format_parser` library, responsible for handling parsing and handling of format arguments as described in the documentation for `std::fmt` [1]. However, since these libraries are written in Rust, GCC in itself is not yet able to compile them. They all depend on the Rust standard library, which we cannot yet compile and link properly. This obviously raises a question - how to actually compile, integrate and distribute these components? We do have the option to rewrite them from scratch, but we feel that spending time on these existing, correct, battle-tested and easily integrable components instead of focusing on other aspects of the language would be a mistake. Spending this time instead on Rust features that we are missing for compiling these components would, in our opinion, yield more results, as it would also help in compiling other Rust programs. We could either distribute these components as compiled libraries, or look at integrating the official Rust compiler to our build system as a temporary measure. I am aware that this would mean restricting the Rust GCC front-end to platforms where the official Rust compiler is also available, which is less than ideal. But that's only for the host part - you can still cross compile to another target and possibly, once the GCC frontend can compile these libraries itself, also use them to bootstrap a hosted version on that target - speaking of .. However, this would only be temporary - as soon as the Rust front-end is able to compile these components, we would simply reuse them and compile them with gccrs as part of our bootstrapping process. .. gccrs would then need to be able to build itself without those modules, at least during stage1 so that the stage1 compiler can then be used to build them. Or you go like m2 and build a "mini-rust" that's just capable of building the modules. Right, that makes a lot of sense. We should definitely be able to build the format string parser without a format string parser, as it does not use format strings for error handling or anything. And even if it did, it would be pretty easy to remove that and do the formatting by hand. Similarly, the borrow checker is not "needed" for compilation and we do plan on building stage1 without it, while making it mandatory for stage2/3 builds. I think re-using parts already available is very sensible at this point. Note that while we might temporarily require a host rust compiler to boostrap gccrs I'd rather not have the build system download something from the internet - so at least the sources of those dependences need to be in the GCC repository, possibly in a new toplevel directory. Okay, that makes a lot of sense. I was thinking of adding a basic check for the Rust compiler to be present when compiling these components - and error out if that isn't the case. Are you suggesting we embed a full copy of rustc in GCC and build it from source when compiling the Rust frontend? Or am I misunderstanding? The documentation for `std::fmt` [1] describes all of the features available in Rust format strings. It also contains a grammar for the format-string parser, which we would need to re-implement on top of supporting all the formatting features. As a prototype, I wrote an FFI interface to the `rustc_format_parser` library and integrated it to our macro expansion system, which took me less than a couple hours. In less than an afternoon, we had bindings for all of the exported types and functions in the library and had access to a compliant and performant Rust format string parser. But re-implementing a correct `format_args!()` parser - with the same performance as the Rust one, and the same amount of features - would probably take days, if not weeks. And we are talking about one of the simplest components we aim to reuse. Something like a fully-compliant trait solver for the Rust programming language would take months if not years to implement properly from scratch. I would like to stress once again that relying on distributing compiled libraries or using `rustc` in our build system would be temporary, and that these measures would be removed as soon as gccrs is able to compile these components from source. I am looking for comments on this decision as well as the best practices we could adopt. Have there been any similar decisions for other self-hosted front-ends? Any previous email threads/commits that you could point me to would be greatly appre
Re: [Request for Comments] Using Rust libraries in the Rust frontend
On 1/25/24 19:19, Richard Biener wrote: Am 25.01.2024 um 16:03 schrieb Arthur Cohen : Hi Richard, On 1/23/24 08:23, Richard Biener wrote: On Mon, Jan 22, 2024 at 7:51 PM Arthur Cohen wrote: Hi everyone, In order to increase the development speed of Rust features, we are seeking feedback on reusing some Rust components directly within our front-end. As mentioned in other conferences, the most important component we would like to integrate into the front-end is the polonius borrow-checker. Another component we've become interested in is the `rustc_format_parser` library, responsible for handling parsing and handling of format arguments as described in the documentation for `std::fmt` [1]. However, since these libraries are written in Rust, GCC in itself is not yet able to compile them. They all depend on the Rust standard library, which we cannot yet compile and link properly. This obviously raises a question - how to actually compile, integrate and distribute these components? We do have the option to rewrite them from scratch, but we feel that spending time on these existing, correct, battle-tested and easily integrable components instead of focusing on other aspects of the language would be a mistake. Spending this time instead on Rust features that we are missing for compiling these components would, in our opinion, yield more results, as it would also help in compiling other Rust programs. We could either distribute these components as compiled libraries, or look at integrating the official Rust compiler to our build system as a temporary measure. I am aware that this would mean restricting the Rust GCC front-end to platforms where the official Rust compiler is also available, which is less than ideal. But that's only for the host part - you can still cross compile to another target and possibly, once the GCC frontend can compile these libraries itself, also use them to bootstrap a hosted version on that target - speaking of .. However, this would only be temporary - as soon as the Rust front-end is able to compile these components, we would simply reuse them and compile them with gccrs as part of our bootstrapping process. .. gccrs would then need to be able to build itself without those modules, at least during stage1 so that the stage1 compiler can then be used to build them. Or you go like m2 and build a "mini-rust" that's just capable of building the modules. Right, that makes a lot of sense. We should definitely be able to build the format string parser without a format string parser, as it does not use format strings for error handling or anything. And even if it did, it would be pretty easy to remove that and do the formatting by hand. Similarly, the borrow checker is not "needed" for compilation and we do plan on building stage1 without it, while making it mandatory for stage2/3 builds. I think re-using parts already available is very sensible at this point. Note that while we might temporarily require a host rust compiler to boostrap gccrs I'd rather not have the build system download something from the internet - so at least the sources of those dependences need to be in the GCC repository, possibly in a new toplevel directory. Okay, that makes a lot of sense. I was thinking of adding a basic check for the Rust compiler to be present when compiling these components - and error out if that isn't the case. Are you suggesting we embed a full copy of rustc in GCC and build it from source when compiling the Rust frontend? Or am I misunderstanding? No, you’d have the format parser and all it’s dependencies in the source tree but rely on an installed rustc to build that. Maybe that doesn’t make sense - I’m not too familiar with the rust compilation model. Ah, no worries that makes total sense! This is what I was planning on doing anyways. If compiling directly with rustc, you can specify paths where the compiler should look for already compiled crates. If you instead use cargo, the Rust build system, you can specify a path for specific dependencies. Thanks, Arthur Richard The documentation for `std::fmt` [1] describes all of the features available in Rust format strings. It also contains a grammar for the format-string parser, which we would need to re-implement on top of supporting all the formatting features. As a prototype, I wrote an FFI interface to the `rustc_format_parser` library and integrated it to our macro expansion system, which took me less than a couple hours. In less than an afternoon, we had bindings for all of the exported types and functions in the library and had access to a compliant and performant Rust format string parser. But re-implementing a correct `format_args!()` parser - with the same performance as the Rust one, and the same amount of features - would probably take days, if not weeks. And we are talking about one of the simplest components we aim to reuse. Somethin
Re: [Request for Comments] Using Rust libraries in the Rust frontend
Hi Iain, On 1/25/24 17:26, Iain Sandoe wrote: Hi Arthur, On 25 Jan 2024, at 15:03, Arthur Cohen wrote: On 1/23/24 08:23, Richard Biener wrote: On Mon, Jan 22, 2024 at 7:51 PM Arthur Cohen wrote: Hi everyone, In order to increase the development speed of Rust features, we are seeking feedback on reusing some Rust components directly within our front-end. As mentioned in other conferences, the most important component we would like to integrate into the front-end is the polonius borrow-checker. Another component we've become interested in is the `rustc_format_parser` library, responsible for handling parsing and handling of format arguments as described in the documentation for `std::fmt` [1]. However, since these libraries are written in Rust, GCC in itself is not yet able to compile them. They all depend on the Rust standard library, which we cannot yet compile and link properly. This obviously raises a question - how to actually compile, integrate and distribute these components? We do have the option to rewrite them from scratch, but we feel that spending time on these existing, correct, battle-tested and easily integrable components instead of focusing on other aspects of the language would be a mistake. Spending this time instead on Rust features that we are missing for compiling these components would, in our opinion, yield more results, as it would also help in compiling other Rust programs. We could either distribute these components as compiled libraries, or look at integrating the official Rust compiler to our build system as a temporary measure. I am aware that this would mean restricting the Rust GCC front-end to platforms where the official Rust compiler is also available, which is less than ideal. But that's only for the host part - you can still cross compile to another target and possibly, once the GCC frontend can compile these libraries itself, also use them to bootstrap a hosted version on that target - speaking of .. However, this would only be temporary - as soon as the Rust front-end is able to compile these components, we would simply reuse them and compile them with gccrs as part of our bootstrapping process. .. gccrs would then need to be able to build itself without those modules, at least during stage1 so that the stage1 compiler can then be used to build them. Or you go like m2 and build a "mini-rust" that's just capable of building the modules. Right, that makes a lot of sense. We should definitely be able to build the format string parser without a format string parser, as it does not use format strings for error handling or anything. And even if it did, it would be pretty easy to remove that and do the formatting by hand. Similarly, the borrow checker is not "needed" for compilation and we do plan on building stage1 without it, while making it mandatory for stage2/3 builds. As long as you leave a route available for porting it to either new (or old) systems which do not have rustc (or any other rust compiler available). E.g. with Ada it is possible to port to a new platform by first building a cross-compiler and then to use that cross-compiler to build a “native cross” (build != host == target) to provide an initial compiler on the target platform. Thanks, this is really helpful. I'll have to figure out how to make that happen in the build system but this is definitely something we'd be interested in doing. Thanks, Arthur Those cross compilers are not bootstrapped (it is a single stage) - but it is reasonable to make it a condition that the $build compiler is the same (even exact) version as the sources you are trying to port to the new platform. thanks Iain I think re-using parts already available is very sensible at this point. Note that while we might temporarily require a host rust compiler to boostrap gccrs I'd rather not have the build system download something from the internet - so at least the sources of those dependences need to be in the GCC repository, possibly in a new toplevel directory. Okay, that makes a lot of sense. I was thinking of adding a basic check for the Rust compiler to be present when compiling these components - and error out if that isn't the case. Are you suggesting we embed a full copy of rustc in GCC and build it from source when compiling the Rust frontend? Or am I misunderstanding? The documentation for `std::fmt` [1] describes all of the features available in Rust format strings. It also contains a grammar for the format-string parser, which we would need to re-implement on top of supporting all the formatting features. As a prototype, I wrote an FFI interface to the `rustc_format_parser` library and integrated it to our macro expansion system, which took me less than a couple hours. In less than an afternoon, we had bindings for all of the exported types and functions in the library and had access to a compliant and perf
Re: [Request for Comments] Using Rust libraries in the Rust frontend
Hi Connor, On 1/25/24 16:55, connor horman wrote: Note that it may not make sense to include a source copy of rustc, as that will itself require an (earlier) stage of rustc to build. mrustc can offer a bootstrap for 1.54, but depending on the versions required, you may need upwards of 10 additional rustc sources. Yes, I was a bit worried about the idea but it seems this is just me not knowing how to read so all is good. Using mrustc for this is a great idea however. Thanks! Arthur On Thu, 25 Jan 2024 at 10:04, Arthur Cohen <mailto:arthur.co...@embecosm.com>> wrote: Hi Richard, On 1/23/24 08:23, Richard Biener wrote: > On Mon, Jan 22, 2024 at 7:51 PM Arthur Cohen mailto:arthur.co...@embecosm.com>> wrote: >> >> Hi everyone, >> >> In order to increase the development speed of Rust features, we are >> seeking feedback on reusing some Rust components directly within our >> front-end. As mentioned in other conferences, the most important >> component we would like to integrate into the front-end is the polonius >> borrow-checker. Another component we've become interested in is the >> `rustc_format_parser` library, responsible for handling parsing and >> handling of format arguments as described in the documentation for >> `std::fmt` [1]. >> >> However, since these libraries are written in Rust, GCC in itself is not >> yet able to compile them. They all depend on the Rust standard library, >> which we cannot yet compile and link properly. This obviously raises a >> question - how to actually compile, integrate and distribute these >> components? >> >> We do have the option to rewrite them from scratch, but we feel that >> spending time on these existing, correct, battle-tested and easily >> integrable components instead of focusing on other aspects of the >> language would be a mistake. Spending this time instead on Rust features >> that we are missing for compiling these components would, in our >> opinion, yield more results, as it would also help in compiling other >> Rust programs. >> >> We could either distribute these components as compiled libraries, or >> look at integrating the official Rust compiler to our build system as a >> temporary measure. I am aware that this would mean restricting the Rust >> GCC front-end to platforms where the official Rust compiler is also >> available, which is less than ideal. > > But that's only for the host part - you can still cross compile to another > target and possibly, once the GCC frontend can compile these libraries > itself, also use them to bootstrap a hosted version on that target - > speaking of .. > >> However, this would only be >> temporary - as soon as the Rust front-end is able to compile these >> components, we would simply reuse them and compile them with gccrs as >> part of our bootstrapping process. > > .. gccrs would then need to be able to build itself without those modules, > at least during stage1 so that the stage1 compiler can then be used to > build them. Or you go like m2 and build a "mini-rust" that's just capable > of building the modules. Right, that makes a lot of sense. We should definitely be able to build the format string parser without a format string parser, as it does not use format strings for error handling or anything. And even if it did, it would be pretty easy to remove that and do the formatting by hand. Similarly, the borrow checker is not "needed" for compilation and we do plan on building stage1 without it, while making it mandatory for stage2/3 builds. > I think re-using parts already available is very sensible at this point. Note > that while we might temporarily require a host rust compiler to boostrap > gccrs I'd rather not have the build system download something from the > internet - so at least the sources of those dependences need to be in the > GCC repository, possibly in a new toplevel directory. Okay, that makes a lot of sense. I was thinking of adding a basic check for the Rust compiler to be present when compiling these components - and error out if that isn't the case. Are you suggesting we embed a full copy of rustc in GCC and build it from source when compiling the Rust frontend? Or am I misunderstanding? >> The documentation for `std::fmt` [1] describes all of th
Re: [PATCH] Fix rust on *-w64-mingw32
Hello,
Thanks a lot for the patch :)
I agree with Jakub that we should be using the GNU coding style in our
call to std::replace - this is what we try to enforce in the rest of the
Rust frontend.
Regarding the changes to `mkdir_wrapped`, the function now looks a bit odd:
void
mkdir_wrapped (const std::string &dirname)
{
int ret;
ret = mkdir (dirname.c_str (), 0775);
(void) ret;
}
could you change it to something simpler like simply ignoring the return
value of `mkdir`? since this is what we are already doing (and we should
improve error handling here... but one battle at a time).
I would suggest the following:
void
mkdir_wrapped (const std::string &dirname)
{
mkdir (dirname.c_str (), 0775);
}
Have you run the testsuite on *-w64-mingw32? I'm wondering if commenting
out the `register_callback` function causes any issues there?
All in all I'm in favor of this patch, and thanks for submitting it :)
Best,
Arthur
GSoC 2021 - Bridging the gap between rustc and gccrs
Hi everyone, It is my pleasure to announce that I will be applying for the Google Summer of Code in order to work under the Rust-GCC organization. I am a french systems programming and embedded systems programming student, and love to work on anything related to the compilation or interpretation of programming languages. I would love for gccrs to become a solid alternative to rustc. I believe that multiple compilers are a necessity for the language to grow and to be available on more platforms. For that, I believe that it is important for gccrs to be usable with Rust's build system, cargo. The subject of my GSoC would therefore be to help make gccrs available under cargo, and make it available for the compilation of small Rust projects. With the help of Philip Herron, I have established the following proposal: https://docs.google.com/document/d/1oUcpU-kGntdQ6FLfSVPP8co3TDJgcdEK2FmvdinlaNc/edit Feel free to leave any comments or suggestions and I'll do my best to apply them. Kind regards, Arthur Cohen
Re: Marc Poulhies appointed Ada co-maintainer
Congratulations Marc! Very happy for you. You deserve all the best. Félicitations :) -- Arthur On Mon, Jul 18, 2022, 19:35 David Edelsohn via Gcc wrote: > I am pleased to announce that the GCC Steering Committee has appointed > Marc Poulhies as Ada co-maintainer. > > Please join me in congratulating Marc on his new role. > > Marc, please update your listing in the MAINTAINERS file. > > Happy hacking! > David >
Re: rust non-free-compatible trademark
Hi Florian, On Mon, Jul 18, 2022, 20:33 Florian Weimer via Gcc wrote: > * lkcl via Gcc: > > > if the Rust Foundation were to add an extremely simple phrase > > > >"to be able to use the word rust in a distributed compiler your > > modifications must 100% pass the test suite without modifying > > the test suite" > > > > then all the problems and pain goes away. > > No. It would actually make matters worse for GCC in this case because > the stated intent is to ship without a borrow checker (“There are no > immediate plans for a borrow checker as this is not required to compile > rust code”, <https://rust-gcc.github.io/>, retrieved 2022-07-18). The website is not up to date and we do have to change that. We do have plans for borrow-checking, which revolve around using and contributing to the Polonius project. There > are of course tests for the borrow checker in the Rust test suite, and > those that check for expected compiler errors will fail with GCC. > > Thanks, > Florian Thanks, -- Arthur Cohen
