[tatterdemalion]

> Having a compiler and standard library written in the language that it compiles has some huge benefits for increasing the pool of possible contributors.

But this isn't the official compiler, this is someone's personal project?

[fyrerise]

> But this isn't the official compiler, this is someone's personal project?

True, but compilers are complicated machines and Rust is still changing at a fairly frantic rate.

The author seems to be doing quite a good job of development today, but if it has any hope of staying current, it probably needs to think about how to increase its bus factor (something happens like changing jobs, starting a family, or they just become interested in something else, and a single person suddenly has less time to contribute).

[steveklabnik]

rust is changing, but in a backwards compatible way. That said the standard library aggressively makes use of new features, so the challenge isn't the language, but compiling libstd.

[tmzt]

Could rustc have a way to output desugared code or code targeting a specific epoch with new features like generators expand to a backwards compatible form. This might allow for preprocessed source that could be compiled by something like mrustc even if it doesn't implement every single RFC?

[steveklabnik]

That's sort of MIR, but we have no intentions of stabilizing it any time soon, if ever.

[tmzt]

Yes, but I mean outputing actual Rust source but with generators or async/await expanded into calls to Futures. Similar to how Go is now bootstrapped from a down-level compiler.

[steveklabnik]

Yeah, I get it. But that's what I mean; MIR is the common sub-language that's the same across epochs.

I don't think there's any real plans for a source-based approach. But epochs can only change a limited amount of things for exactly this reason; they minimize the compiler burden of supporting them.