(Re)Using rustc components in gccrs
rust-gcc.github.io
rust-gcc.github.io
> 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.
> 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.
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.
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.)
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”.
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.
It's not like Polonius or the trait solver were designed with bootstrapping gccrs in mind.
I'm pretty sure they weren't. The Rust bootstrap chain is ridiculously long.