Re: Rust front-end
On Fri, Jul 8, 2022 at 7:32 PM Philip Herron wrote: > > 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? Yes, that's the prefered way. Having an integration branch ready for people to play with is also useful - if you are ready you might want to push something like that to the gcc.gnu.org repository under the devel/ namespace. Thanks, Richard. > 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 supporte
Re: [RFC] Using std::unique_ptr and std::make_unique in our code
Hi! On 2022-07-08 9:46 p.m., David Malcolm via Gcc wrote: > - pending_diagnostic *d, > + std::unique_ptr d, I see that you didn't add any typedef for std::unique_ptr in this patch. It will be inevitable that people will start adding them, for conciseness, IME, though. To avoid diverging naming styles for such typedefs in the codebase, GDB settled on using the "_up" suffix (for Unique Pointer) quite early in the C++11 conversion, and we use such typedefs pervasively nowadays. For example, for the type above, we'd have: typedef std::unique_ptr pending_diagnostic_up; and then: - pending_diagnostic *d, + pending_diagnostic_up d, I would suggest GCC have a similar guideline, before people start using foo_ptr, bar_unp, quux_p, whatnot diverging styles. And it would be nice if GCC followed the same nomenclature style as GDB, so we could have one single guideline for the whole GNU toolchain, so people moving between codebases only had to learn one guideline. Pedro Alves
Auto generate header file
What if we use auto generate header file tool in our project.
Re: Rust front-end
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
Re: [RFC] Using std::unique_ptr and std::make_unique in our code
On Mon, 2022-07-11 at 11:56 +0100, Pedro Alves wrote: > Hi! > > On 2022-07-08 9:46 p.m., David Malcolm via Gcc wrote: > > - pending_diagnostic *d, > > + > > std::unique_ptr d, > > I see that you didn't add any typedef for std::unique_ptr in > this patch. It will be > inevitable that people will start adding them, for conciseness, IME, > though. Perhaps, but right now I prefer to spell out std::unique_ptr, since I'm not as comfortable with C++11 as I might be. > To avoid diverging > naming styles for such typedefs in the codebase, GDB settled on using > the "_up" suffix (for Unique Pointer) > quite early in the C++11 conversion, and we use such typedefs > pervasively nowadays. For example, for the type > above, we'd have: > > typedef std::unique_ptr pending_diagnostic_up; > > and then: > > - pending_diagnostic *d, > + pending_diagnostic_up d, > > I would suggest GCC have a similar guideline, before people start > using foo_ptr, > bar_unp, quux_p, whatnot diverging styles. Thanks for the info. I suspect the gdb community is much more comfortable with C++ (and C++11) than the gcc community. The recommendation sounds reasonable for if/when we start adding such typedefs, but, as I said, for now I think I want to spell out std::unique_ptr in the few places I'm using it. Hope this makes sense, and these are just my opinions, of course Dave > > And it would be nice if GCC followed the same nomenclature style as > GDB, so we could > have one single guideline for the whole GNU toolchain, so people > moving between codebases > only had to learn one guideline. > > Pedro Alves >
