7 ms·

I'm not sure if what I'm asking makes sense, but since it's written for a new backend, would the authors have to bootstrap it using a different toolchain? I gue

I'm not sure if what I'm asking makes sense, but since it's written for a new backend, would the authors have to bootstrap it using a different toolchain? I guess what I'm asking is, could they use the LLVM Rust to build the GCC frontend or do they have to start all over with a different base language to get a first working version of a rust compiler?

gumby 6y ago
It's not written in rust; gcc is written in c. There is no bootstrapping involved.
- faitswulff 6y ago
  Do gcc languages - even low level ones - remain written in c?
  - guerby 6y ago
    The GCC Ada frontend is written in Ada: https://gcc.gnu.org/wiki/GNAT https://gcc.gnu.org/wiki/GNAT There is also a port of the Ada frontend to LLVM backend: https://github.com/AdaCore/gnat-llvm https://github.com/AdaCore/gnat-llvm
  - pjmlp 6y ago
    Besides the Ada example, GDC shares the D frontend, written in D, with other D implementations.
- Narishma 6y ago
  C++ but yes.
- NieDzejkob 6y ago
  GCC is no longer written in C, but in C++. They switched after GCC 4.7.
  - saagarjha 6y ago
    Of course, much of the code is still C.
singron 6y ago
As far as I can tell, this is written in C++ like the rest of GCC, so they don't need a rust compiler to bootstrap.
- faitswulff 6y ago
  I see, so it’s written in C++. Would it remain that way, though? AFAIK the LLVM Rust is, itself, written in Rust, right? I imagine that it would be a goal to do the same for gcc.
  - strongdenial 6y ago
    There is absolutely no reason why the GCC front-end needs to be written in Rust. The reason the LLVM front-end was written in Rust initially was so they could immediately test and use new features in what was at the time also the largest program in Rust. Re-writing the GCC front-end in Rust would just prolong an already rather unfortunate bootstrap problem with the language and it should be strongly discouraged. As it stands, the way to bootstrap the official Rust compiler from source with just a C/C++ compiler is a few options: * Compile OCaml (implemented in C), use it to build the original Rust front-end in OCaml and then build each successive version of the language until you hit 1.49. This option is not fun. * Compile mrustc, which is a C++ implemented compiler that supports Rust 1.29. Use that to build the actual Rust 1.29 and then iterate building your way all the way to 1.49. That is less bad, but still not fun. * Compile the 1.49 compiler to WASM and run it via a C/C++ implemented runtime in order to compile itself on the target system. This would also mean packaging and distributing the WASM generated code, which some distributions would refuse. I also am not sure if it's even currently feasible, as I don't follow the WASM situation closely. A compliant, independent C++ implementation that could be built in the ten minutes it takes to build GCC itself would be a very good thing to have and would be more friendly to distribution maintainers.
    - varajelle 6y ago
      > There is absolutely no reason why the GCC front-end needs to be written in Rust. How about memory safety and fearless concurrency?
oconnor663 6y ago
The LLVM-based Rust compiler uses a lot of unstable/nightly-only Rust features internally. So even if this project got to the point where it could compile all stable Rust programs, I think it would take quite a bit more work than that to be able to compile `rustc` itself. (It might be that the unstable stuff is mostly in the standard library and not the compiler itself? Does it make a difference?)
- steveklabnik 6y ago
  > It might be that the unstable stuff is mostly in the standard library and not the compiler itself? Does it make a difference? It might. There are at least two major things off the top of my head, regarding libstd: 1. specialization is needed for performance around String and &str 2. const generics are needed to support some trait implementations We currently allow some stuff like this to leak through, in a sense, when we're sure that we're actually going to be making things stable someday. An alternative compiler could patch out 1, and accept slower code, but 2 would require way more effort. There has been some discussion about trying to remove unstable features from the compiler itself, specifically to make it easier to contribute to, but it unlikely that it will be completely removed from the current implementation of libstd for some time.
  - CodesInChaos 6y ago
    Doesn't min_const_generics (stable once 1.51 releases on 2021-03-25) cover everything std needs (implementing traits for arbitrary array sizes)?
    - steveklabnik 6y ago
      I believe that it does, yes. We haven't hit that in stable yet, though, so I am speaking purely in the present. You're right that it's looking good for stabilization in a few months, but anything can happen, in theory. I'm more trying to illustrate the point, that significant features can depend on something that's unstable currently. Those impls landed well before it was even marked as being stable in nightly.
- deleted 6y ago
rcxdude 6y ago
If it was written in rust, there's no reason they couldn't use LLVM rust to start development until it became self-hosting. (Same as you can develop a self-hosting C compiler by starting with gcc)

gumby 6y ago

It's not written in rust; gcc is written in c. There is no bootstrapping involved.

faitswulff 6y ago
Do gcc languages - even low level ones - remain written in c?
- guerby 6y ago
  The GCC Ada frontend is written in Ada: https://gcc.gnu.org/wiki/GNAT https://gcc.gnu.org/wiki/GNAT There is also a port of the Ada frontend to LLVM backend: https://github.com/AdaCore/gnat-llvm https://github.com/AdaCore/gnat-llvm
- pjmlp 6y ago
  Besides the Ada example, GDC shares the D frontend, written in D, with other D implementations.
Narishma 6y ago
C++ but yes.
NieDzejkob 6y ago
GCC is no longer written in C, but in C++. They switched after GCC 4.7.
- saagarjha 6y ago
  Of course, much of the code is still C.

singron 6y ago

As far as I can tell, this is written in C++ like the rest of GCC, so they don't need a rust compiler to bootstrap.

faitswulff 6y ago
I see, so it’s written in C++. Would it remain that way, though? AFAIK the LLVM Rust is, itself, written in Rust, right? I imagine that it would be a goal to do the same for gcc.
- strongdenial 6y ago
  There is absolutely no reason why the GCC front-end needs to be written in Rust. The reason the LLVM front-end was written in Rust initially was so they could immediately test and use new features in what was at the time also the largest program in Rust. Re-writing the GCC front-end in Rust would just prolong an already rather unfortunate bootstrap problem with the language and it should be strongly discouraged. As it stands, the way to bootstrap the official Rust compiler from source with just a C/C++ compiler is a few options: * Compile OCaml (implemented in C), use it to build the original Rust front-end in OCaml and then build each successive version of the language until you hit 1.49. This option is not fun. * Compile mrustc, which is a C++ implemented compiler that supports Rust 1.29. Use that to build the actual Rust 1.29 and then iterate building your way all the way to 1.49. That is less bad, but still not fun. * Compile the 1.49 compiler to WASM and run it via a C/C++ implemented runtime in order to compile itself on the target system. This would also mean packaging and distributing the WASM generated code, which some distributions would refuse. I also am not sure if it's even currently feasible, as I don't follow the WASM situation closely. A compliant, independent C++ implementation that could be built in the ten minutes it takes to build GCC itself would be a very good thing to have and would be more friendly to distribution maintainers.
  - varajelle 6y ago
    > There is absolutely no reason why the GCC front-end needs to be written in Rust. How about memory safety and fearless concurrency?

oconnor663 6y ago

The LLVM-based Rust compiler uses a lot of unstable/nightly-only Rust features internally. So even if this project got to the point where it could compile all stable Rust programs, I think it would take quite a bit more work than that to be able to compile `rustc` itself. (It might be that the unstable stuff is mostly in the standard library and not the compiler itself? Does it make a difference?)

steveklabnik 6y ago
> It might be that the unstable stuff is mostly in the standard library and not the compiler itself? Does it make a difference? It might. There are at least two major things off the top of my head, regarding libstd: 1. specialization is needed for performance around String and &str 2. const generics are needed to support some trait implementations We currently allow some stuff like this to leak through, in a sense, when we're sure that we're actually going to be making things stable someday. An alternative compiler could patch out 1, and accept slower code, but 2 would require way more effort. There has been some discussion about trying to remove unstable features from the compiler itself, specifically to make it easier to contribute to, but it unlikely that it will be completely removed from the current implementation of libstd for some time.
- CodesInChaos 6y ago
  Doesn't min_const_generics (stable once 1.51 releases on 2021-03-25) cover everything std needs (implementing traits for arbitrary array sizes)?
  - steveklabnik 6y ago
    I believe that it does, yes. We haven't hit that in stable yet, though, so I am speaking purely in the present. You're right that it's looking good for stabilization in a few months, but anything can happen, in theory. I'm more trying to illustrate the point, that significant features can depend on something that's unstable currently. Those impls landed well before it was even marked as being stable in nightly.
deleted 6y ago

rcxdude 6y ago

If it was written in rust, there's no reason they couldn't use LLVM rust to start development until it became self-hosting. (Same as you can develop a self-hosting C compiler by starting with gcc)