7 ms·

It's important to note that mrustc is not intended for everyday use and instead as a bootstrap compiler for rustc (at least originally). We would like to devel

It's important to note that mrustc is not intended for everyday use and instead as a bootstrap compiler for rustc (at least originally). We would like to develop an alternative that is suitable as a daily rust compiler and that integrates into the existing Rust ecosystem (and makes use of it!)

kzrdude 4y ago
That's claimed for two reasons - bootstrapping is the first milestone of a working and useful rust compiler. In this case; if it couldn't be used for anything else, at least it could do that. It's also claimed that "it will only be that" to seem more non-threatening to the main Rustc project. If it was “easy” to do, mrustc would of course support all of the Rust language. Maybe it will get there if there is enough work and interest. There was this vague concern about splitting the ecosystem. The concern is understandable - to an ecosystem that has been "in control" by a central implementation for a decade. I would file it under growing pains. Rust can't, when it grows up, always be a single-implementation language.
- hvdijk 4y ago
  You're saying the project's maintainer is deliberately misrepresenting mrustc's goals in order to prevent malicious interference by the Rust community? Both of those seem very unlikely to me and I can't see anything in your message to provide support for those claims. I see no reason not to just take things at face value here.
  - kzrdude 4y ago
    In fact the project itself doesn't claim it will only be that. But in the community, this idea is still spread around.
  - kibwen 4y ago
    Rather than being afraid of interference, the reason that the mrustc author is so careful in their wording is that nobody has ever bothered to define what it means to be a "compatible" implementation of Rust, which is a semantic and legal hurdle that the implementation in the OP will have to clear. In a more concrete sense, mrustc can't currently be a compatible implementation of Rust, because (by dint of lacking a borrow Checker) it accepts more programs than rustc does (arguably it's fine to accept strictly fewer programs than rustc does and still be called a compatible implementation).
    - dodobirdlord 4y ago
      Notably, mrustc is a Rust compiler in the sense that it is able to compile valid Rust code. It does not provide a guarantee that it will reject invalid input. The user is on the hook to work out themselves through some other mechanism that their code is valid before calling mrustc. This is fine for a project with the goal of providing an alternative bootstrapping path for rustc. The rustc codebase is known to be valid Rust, more or less by definition, since rustc is self-hosting and Rust is defined by rustc’s implementation rather than by a specification.
- fulafel 4y ago
  The mrustc page says: > This project is a "simple" rust compiler written in C++ that is able to bootstrap a "recent" rustc, but may eventually become a full separate re-implementation. So it's a compatible statement to say that it's currently a bootstrap compiler.
- infamouscow 4y ago
  > There was this vague concern about splitting the ecosystem. The concern is understandable - to an ecosystem that has been "in control" by a central implementation for a decade. I would file it under growing pains. Rust can't, when it grows up, always be a single-implementation language. This is why formal specifications matter. The Rust community say languages like C and C++ didn't have specifications for a while. That's true, but it's a flimsy argument because the development velocity of both C and C++ prior to formalization were a fraction of Rust's current velocity. C and C++ also had fewer features pre-specification than Rust has pre-specification. Rust is also continuing to add features. Without a specification how do we know which Rust implementation is correct and which has bugs? It's easy to point to the reference implementation in 2022, but that could change in five or ten years. What happens if drama from within the reference project causes a fork? People like to imagine forks as easy to differentiate, but it's never that simple. It's almost always very nuanced, gray, and muddy with very good arguments on both sides. Which implementation is the correct Rust in that case? None of this is clear or obvious.
  - steveklabnik 4y ago
    > Without a specification how do we know which Rust implementation is correct and which has bugs? The gcc-rs project answers this question explicitly in their FAQ, which I've linked downthread: > If gccrs interprets a program differently from rustc, this is considered a bug. They also go on to say: > Once Rust-GCC can compile and verify all Rust programs, this can also help figure out any inconsistencies in the specification of features in the language. This should help to get features right in both compilers before they are stabilized. If you're looking for a specification, additional implementations help that effort, not hurt it.
  - tialaramex 4y ago
    > This is why formal specifications matter. The most generous response I could give to that is "Maybe". You mentioned C and C++ several times, but for C++ what actually happened is that they just shipped a half dozen distinct languages with the name C++ in different years. C++ 98 and C++ 20 are similar languages, but only in the same way that the 1998 Ford Fiesta and the 2020 Ford Fiesta are similar cars. They're occupying the same niche, some of the fittings are familiar, others are not. Many of the parts are different. Rust has no plans to do that. If you have some code that went on the shelf in 2015 for Rust 1.0 and blow dust off it, it compiles with a brand new Rust compiler today in 2022, and works just fine along side brand new code written today. Actually almost all of it could still be pasted in to new code, although some of it would look a bit unnecessary and clunky to a new Rust programmar, "Grandad -", for example they might ask, "Why are you specifying the type here when it would obviously be inferred correctly anyway?". Well, in 2015 that type wouldn't have been inferred. > Without a specification how do we know which Rust implementation is correct and which has bugs? Reading exercise for you: Look up "Pointer Provenance" and read about the problem. Then, read whatever version of C++ "formal specification" you think you're relying on. Huh, it doesn't mention provenance anywhere in this document. You may need to go back and re-read the stuff you read at this point. This is a difficult problem, and the compiler must care about it deeply to produce reasonable machine code for even fairly simple programs. But the specification doesn't mention it. What does that mean? I'll save you some time: The compilers do not implement the standard, and they haven't for decades. What they implement resembles the specification but not very closely and never where it conflicts with their duty to generate machine code you'd actually be willing to run. Some C++ programmers are very angry about that, but WG21 shows no sign of doing anything about it decades later. C++ 23 still won't fix the provenance problem, it will once again be kicked into the long grass. Even aside from provenance and similar issues, C++ is riddled with Soundness bugs where your program is meaningless and basically the compiler, being pragmatic, will do something but it's unspecified what. This type of problem relies on a get out in the C++ Standards Document triggered by the phrase "Ill-formed, no diagnostic required" meaning what you wrote isn't a C++ program and none of the rules in this standard apply but your conforming C++ compiler may not even warn you about this, it might compile your code anyway, even though what (if anything) it does is entirely arbitrary.

kzrdude 4y ago

That's claimed for two reasons - bootstrapping is the first milestone of a working and useful rust compiler. In this case; if it couldn't be used for anything else, at least it could do that. It's also claimed that "it will only be that" to seem more non-threatening to the main Rustc project. If it was “easy” to do, mrustc would of course support all of the Rust language. Maybe it will get there if there is enough work and interest. There was this vague concern about splitting the ecosystem. The concern is understandable - to an ecosystem that has been "in control" by a central implementation for a decade. I would file it under growing pains. Rust can't, when it grows up, always be a single-implementation language.

hvdijk 4y ago
You're saying the project's maintainer is deliberately misrepresenting mrustc's goals in order to prevent malicious interference by the Rust community? Both of those seem very unlikely to me and I can't see anything in your message to provide support for those claims. I see no reason not to just take things at face value here.
- kzrdude 4y ago
  In fact the project itself doesn't claim it will only be that. But in the community, this idea is still spread around.
- kibwen 4y ago
  Rather than being afraid of interference, the reason that the mrustc author is so careful in their wording is that nobody has ever bothered to define what it means to be a "compatible" implementation of Rust, which is a semantic and legal hurdle that the implementation in the OP will have to clear. In a more concrete sense, mrustc can't currently be a compatible implementation of Rust, because (by dint of lacking a borrow Checker) it accepts more programs than rustc does (arguably it's fine to accept strictly fewer programs than rustc does and still be called a compatible implementation).
  - dodobirdlord 4y ago
    Notably, mrustc is a Rust compiler in the sense that it is able to compile valid Rust code. It does not provide a guarantee that it will reject invalid input. The user is on the hook to work out themselves through some other mechanism that their code is valid before calling mrustc. This is fine for a project with the goal of providing an alternative bootstrapping path for rustc. The rustc codebase is known to be valid Rust, more or less by definition, since rustc is self-hosting and Rust is defined by rustc’s implementation rather than by a specification.
fulafel 4y ago
The mrustc page says: > This project is a "simple" rust compiler written in C++ that is able to bootstrap a "recent" rustc, but may eventually become a full separate re-implementation. So it's a compatible statement to say that it's currently a bootstrap compiler.
infamouscow 4y ago
> There was this vague concern about splitting the ecosystem. The concern is understandable - to an ecosystem that has been "in control" by a central implementation for a decade. I would file it under growing pains. Rust can't, when it grows up, always be a single-implementation language. This is why formal specifications matter. The Rust community say languages like C and C++ didn't have specifications for a while. That's true, but it's a flimsy argument because the development velocity of both C and C++ prior to formalization were a fraction of Rust's current velocity. C and C++ also had fewer features pre-specification than Rust has pre-specification. Rust is also continuing to add features. Without a specification how do we know which Rust implementation is correct and which has bugs? It's easy to point to the reference implementation in 2022, but that could change in five or ten years. What happens if drama from within the reference project causes a fork? People like to imagine forks as easy to differentiate, but it's never that simple. It's almost always very nuanced, gray, and muddy with very good arguments on both sides. Which implementation is the correct Rust in that case? None of this is clear or obvious.
- steveklabnik 4y ago
  > Without a specification how do we know which Rust implementation is correct and which has bugs? The gcc-rs project answers this question explicitly in their FAQ, which I've linked downthread: > If gccrs interprets a program differently from rustc, this is considered a bug. They also go on to say: > Once Rust-GCC can compile and verify all Rust programs, this can also help figure out any inconsistencies in the specification of features in the language. This should help to get features right in both compilers before they are stabilized. If you're looking for a specification, additional implementations help that effort, not hurt it.
- tialaramex 4y ago
  > This is why formal specifications matter. The most generous response I could give to that is "Maybe". You mentioned C and C++ several times, but for C++ what actually happened is that they just shipped a half dozen distinct languages with the name C++ in different years. C++ 98 and C++ 20 are similar languages, but only in the same way that the 1998 Ford Fiesta and the 2020 Ford Fiesta are similar cars. They're occupying the same niche, some of the fittings are familiar, others are not. Many of the parts are different. Rust has no plans to do that. If you have some code that went on the shelf in 2015 for Rust 1.0 and blow dust off it, it compiles with a brand new Rust compiler today in 2022, and works just fine along side brand new code written today. Actually almost all of it could still be pasted in to new code, although some of it would look a bit unnecessary and clunky to a new Rust programmar, "Grandad -", for example they might ask, "Why are you specifying the type here when it would obviously be inferred correctly anyway?". Well, in 2015 that type wouldn't have been inferred. > Without a specification how do we know which Rust implementation is correct and which has bugs? Reading exercise for you: Look up "Pointer Provenance" and read about the problem. Then, read whatever version of C++ "formal specification" you think you're relying on. Huh, it doesn't mention provenance anywhere in this document. You may need to go back and re-read the stuff you read at this point. This is a difficult problem, and the compiler must care about it deeply to produce reasonable machine code for even fairly simple programs. But the specification doesn't mention it. What does that mean? I'll save you some time: The compilers do not implement the standard, and they haven't for decades. What they implement resembles the specification but not very closely and never where it conflicts with their duty to generate machine code you'd actually be willing to run. Some C++ programmers are very angry about that, but WG21 shows no sign of doing anything about it decades later. C++ 23 still won't fix the provenance problem, it will once again be kicked into the long grass. Even aside from provenance and similar issues, C++ is riddled with Soundness bugs where your program is meaningless and basically the compiler, being pragmatic, will do something but it's unspecified what. This type of problem relies on a get out in the C++ Standards Document triggered by the phrase "Ill-formed, no diagnostic required" meaning what you wrote isn't a C++ program and none of the rules in this standard apply but your conforming C++ compiler may not even warn you about this, it might compile your code anyway, even though what (if anything) it does is entirely arbitrary.