(Re)Using rustc components in gccrs(rust-gcc.github.io)
rust-gcc.github.io
(Re)Using rustc components in gccrs
https://rust-gcc.github.io/2024/09/20/reusing-rustc-components.html
23 comments
Love seeing updates / progress on gccrs.
Why not reuse the whole frontend then?
Its their itch to scratch, and its good to have an independent implementation anyway
Because we want to plug into GCC, so that we can use the rest of the compiler chain to output to all of the architectures that GCC supports.
You still get that by using the same Rust frontend and using GCC instead of LLVM as the backend. A parallel reimplemented from scratch front end at best lets you find under-specified aspects of the current implementation. Not sure it actually helps the ecosystem though.
You're describing rustc_codegen_gcc
Correct. I’m saying that the justification provided:
> Because we want to plug into GCC, so that we can use the rest of the compiler chain to output to all of the architectures that GCC supports.
is invalidated by rust_codegen_gcc and thus is not a good reason for a new frontend.
> Because we want to plug into GCC, so that we can use the rest of the compiler chain to output to all of the architectures that GCC supports.
is invalidated by rust_codegen_gcc and thus is not a good reason for a new frontend.
Discovery and improvement of "under-specified aspects of the current implementation" can have a large practical impact, and implementing a standard (the Rust language) more than once so that it ceases to have a dominant "current implementation" (rustc) is even more important.
That’s me being very very generous and just restating the supposed goal of this effort since rust_codegen_gcc provides a much better solution to the “I want to be able to hit all the gcc targets”.
I’m not actually convinced that a new fronted actually helps as much for that effort especially when weighed against the very real downsides we see in c and c++. I have a strong suspicion that addressing under specified parts of the current implementation can be done more cheaply and effectively using other mechanisms.
Indeed, I don’t see the typescript community really complaining that there isn’t another implementation of typescript. And cpython remains the de facto Python implementation with other distributions seeing less adoption due to network effects and I don’t really see cpython benefiting from the existence of the other frontends.
I’m not actually convinced that a new fronted actually helps as much for that effort especially when weighed against the very real downsides we see in c and c++. I have a strong suspicion that addressing under specified parts of the current implementation can be done more cheaply and effectively using other mechanisms.
Indeed, I don’t see the typescript community really complaining that there isn’t another implementation of typescript. And cpython remains the de facto Python implementation with other distributions seeing less adoption due to network effects and I don’t really see cpython benefiting from the existence of the other frontends.
> Indeed, I don’t see the typescript community really complaining that there isn’t another implementation of typescript.
There are actually numerous third-party implementations that can take TypeScript code and compile it to JavaScript. Babel can do it in pure JS/TS, SWC can do it in Rust, and ESBuild can do it in Golang.
The catch is that AFAIK none of these implementations enforce the actual type checks. This is usually called "type stripping" within the JavaScript community, but it's basically equivalent to the "Rust without the borrow checker" implementation that gccrs is working on.
Well, except that the Rust community is extremely ideologically opposed to "Rust compiler without the borrow checker" existing as a viable product, so you end up with the situation described in the article where that implementation is just used to compile a hybrid compiler with all the hard-to-implement type-checker stuff copied verbatim from rustc. That erases most of the spec-robustness benefits of doing a full third-party implementation, but there are still some practical benefits, like being able to bootstrap the compiler more easily.
And who knows -- if you hack the build to re-disable the borrow checker, the resulting compiler might run faster. (That's the main benefit of the third-party TypeScript implementations in practice.)
There are actually numerous third-party implementations that can take TypeScript code and compile it to JavaScript. Babel can do it in pure JS/TS, SWC can do it in Rust, and ESBuild can do it in Golang.
The catch is that AFAIK none of these implementations enforce the actual type checks. This is usually called "type stripping" within the JavaScript community, but it's basically equivalent to the "Rust without the borrow checker" implementation that gccrs is working on.
Well, except that the Rust community is extremely ideologically opposed to "Rust compiler without the borrow checker" existing as a viable product, so you end up with the situation described in the article where that implementation is just used to compile a hybrid compiler with all the hard-to-implement type-checker stuff copied verbatim from rustc. That erases most of the spec-robustness benefits of doing a full third-party implementation, but there are still some practical benefits, like being able to bootstrap the compiler more easily.
And who knows -- if you hack the build to re-disable the borrow checker, the resulting compiler might run faster. (That's the main benefit of the third-party TypeScript implementations in practice.)
Typescript was written very intentionally to be really easy to transpile to JS which is why you see so many solutions. The type checking piece remains not reimplemented despite high profile third party attempts to rewrite it in a faster language. The type checking piece is exactly the thing that makes typescript typescript. And the reason the external frontend attempt failed is that it can’t keep up with mainline development which is also true for CPython and its offshoots. In fact, TS is so easy to strip that the syntax is being standardized within official ecmascript so that any type checking annotations could be layered into JS code and engines would natively strip without needing transpolation in the first place.
As for “rust without the borrow checker” it’s very much not the same thing as Typescript transpilation for many reasons among which are that there are many other language rules would still have to be enforced. It’s akin to making a TS type checker that didn’t validate 1 of the language rules but enforced the others.
I’m not opposed to a compilation mode that didn’t enforce the borrow checker but repeated tests of compiling various software packages reveal that the borrow checker is within the noise performance wise. So you’d need a more compelling reason than “maybe it runs faster”.
As for “rust without the borrow checker” it’s very much not the same thing as Typescript transpilation for many reasons among which are that there are many other language rules would still have to be enforced. It’s akin to making a TS type checker that didn’t validate 1 of the language rules but enforced the others.
I’m not opposed to a compilation mode that didn’t enforce the borrow checker but repeated tests of compiling various software packages reveal that the borrow checker is within the noise performance wise. So you’d need a more compelling reason than “maybe it runs faster”.
> repeated tests of compiling various software packages reveal that the borrow checker is within the noise performance wise.
Out of curiosity, do you have a source for this? The stuff I remember reading on the topic is from back in 2018 where they managed to get the NLL borrow checker to be not much slower than the old borrow checker (https://blog.mozilla.org/nnethercote/2018/11/06/how-to-speed...) -- but that took a concerted effort, and the borrow checker was overall a large enough contributor to compilation time that it was worth spending a bunch of effort optimizing it.
Out of curiosity, do you have a source for this? The stuff I remember reading on the topic is from back in 2018 where they managed to get the NLL borrow checker to be not much slower than the old borrow checker (https://blog.mozilla.org/nnethercote/2018/11/06/how-to-speed...) -- but that took a concerted effort, and the borrow checker was overall a large enough contributor to compilation time that it was worth spending a bunch of effort optimizing it.
rustc_codegen_gcc is also a thing.
I guess this doesn't solve the bootstrapping issue.
Neither does this project of it contains parts that needs a rust compiler to be bootstrapped
It is the Rust compiler, the article describes how the (Rust) compiler is first compiled without the Rust code in it and then used to bootstrap the final version which does have the Rust code in it
incorrect, this is a re-implementation of rust by designed to be included in gcc, not the original rust compiler.
You didn't read the part about compiling with the borrow checker turned off?
I'm kind of curious how many components you can jettison from a Rust compiler and still be able to build these libraries.
It's not like Polonius or the trait solver were designed with bootstrapping gccrs in mind.
It's not like Polonius or the trait solver were designed with bootstrapping gccrs in mind.
If these compiler components were designed to conform to almost implementation-agnostic bootstrapping stages (e.g. compiling the borrow checker without checking borrows) organizing gccrs bootstrapping like rustc bootstrapping enables reuse.
> If these compiler components were designed to conform to almost implementation-agnostic bootstrapping stages
I'm pretty sure they weren't. The Rust bootstrap chain is ridiculously long.
I'm pretty sure they weren't. The Rust bootstrap chain is ridiculously long.
Makes sense
> First, we use a C++ compiler to build gccrs, disabling the borrow-checking pass of the compiler. It is important to ensure borrow-checking cannot be disabled at runtime using a command line flag, as this could have a negative impact on the Rust ecosystem – however, building gccrs without borrow-checking to use it as an intermediate compiler in our bootstrapping process is okay.