[nayak]

This series was in response to another thread [1] which wanted to make rust mandatory in an upcoming release.

The authors proposal was to instead take the middle ground and use rust as an optional dependency until a later point of time where it becomes mandatory.

The later point of time was decided based on when rust support lands in gcc, which would make things smoother, since platforms which support gcc would also be included.

[1]: https://lore.kernel.org/git/pull.1980.git.git.1752784344.git...

[djha-skin]

The GCC compiler collection has been hit and miss though. Nobody uses gcj for example. I sort of doubt that they'll be able to implement a good compiler for a language that doesn't even have a standard without that implementation going wildly out of date in the future, just like what happened with Java.

[oldsecondhand]

Since OpenJDK was released there isn't much point maintaining GCJ.

[aw1621107]

There's two different methods by which Rust support can be added to GCC: adding a Rust frontend to GCC and adding a GCC backend to the Rust compiler (rustc_codegen_gcc). The latter approach would not be (as?) susceptible to implementation divergence as an independent frontend.

[1718627440]

I hope for the former since then the functionality might become available as attributes in C too.

[aw1621107]

Might depend on the specific feature. If Clang is any indication I wouldn't hold out hope that (frontend?) features like lifetimes/borrow checking are easily transferable.

In any case, there is work on a Rust frontend for GCC (gccrs), but I haven't seen any discussion on whether any of the Rust-specific features can benefit other GCC frontends. Might be a bit premature for those discussions anyways since the frontend has yet to reach production readiness.

[1718627440]

The compiler has already the concept of scope and variables existing at least in the optimizer. Ownership tracking programs for C have been existing for 20 years, so it can't be too hard to integrate it in the compiler, once it has been implemented for one language.

[aw1621107]

> The compiler has already the concept of scope and variables existing at least in the optimizer.

My gut feeling is that while the high-level concepts might share a name I'm not actually sure if they're similar enough for useful transfer? The optimizer is working on a very different representation at a later stage of the compilation process, so I'm a bit skeptical about the level of similarity and/or transferability when you get down to details. I guess a more concrete example might be like comparing type inference with optimizer value range analysis - both will analyze a CFG, but beyond that they're working on different-enough representations that transforming work on the latter to useful work on the former seems unlikely to me (though I'm a nobody, so take that with an appropriate grain of salt).

For example, consider work on improved lifetime analysis in Clang [0], which seems to be discussing a from-scratch implementation based on concepts from Polonius and doesn't seem to reference anything from LLVM. And more generally, the fact that neither GCC nor Clang appear to have discussed reusing concepts from their optimizer passes to recreate the borrow checker or borrow checker-like functionality makes it seem more likely to me that there's some fundamental distinction and/or additional considerations that make such a project difficult.

> Ownership tracking programs for C have been existing for 20 years

Could you give some examples? Not sure I've heard of anything that would fill the same niche as the borrow checker.

> so it can't be too hard to integrate it in the compiler, once it has been implemented for one language.

Sorry, I'm getting a bit confused here. When you say "integrate it in the compiler", by "it" do you mean the above mentioned "ownership tracking programs for C", or do you mean features implemented in the GCC Rust frontend?

In any case, as far as the borrow checker goes gccrs is currently planning on reusing rustc's borrowck implementation so that's going to be a bit of a hurdle to integrating similar functionality into other frontends. I don't know whether they plan on eventually writing an independent borrow checking implementation. Not sure if you had other features in mind, either.

[0]: https://discourse.llvm.org/t/rfc-intra-procedural-lifetime-a...

[nextaccountic]

yep, if git is content with rustc_codegen_gcc, then it's very doable they can require rust in the next few years