21–30 of 179 posts
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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.
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 i…
How about memory safety and fearless concurrency?
Is a great deal of actual Rust behavior not fairly intimately tied to LLVM ? As far as I know it leaks various LLVM details and much of the documentation about various functions documents them as being little more than a thin wrapper to various LLVM internals.
Is a great deal of actual Rust behavior not fairly intimately tied to LLVM ? As far as I know it leaks various LLVM details and much of the documentation about various functions documents them as being little more than a thin wrapper to various LLVM internals.
What I really hope is that the Rust community doesn’t go out of its way to make this easier. Communicate and let value come back but there’s an significant amount of value in keeping a single backend relies on. CPython has done the Python community a lot of good by keeping one official compiler/tool chain (despite the great work done by projects like JPython/PyPy). The only way to do this properly, if desirable, is t…
No. The correct way is to create a Rust language specification that describes what the correct behavior is.
Then whether LLVM, GCC, or something else is used does not matter. There won't be one implementation with defacto behavior, there will be multiple implementations that follow the spec.
This is the way mature languages work.
Earlier quoted context omitted.
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 i…
> There is absolutely no reason why the GCC front-end needs to be written in Rust. How about memory safety and fearless concurrency?
Keeping a viable C++ implementation as part of GCC would be the smartest decision.
The timeline looks rather ambitious https://github.com/Rust-GCC/gccrs/milestones
This is excellent; there's embedded targets that LLVM doesn't officially support and GCC does.
GCC is also roughly even in compilation speed now https://www.phoronix.com/scan.php?page=news_item&px=GCC-Fast...
LLVM is much easier to work with internally but GCC is a seriously good compiler even now.
Is a great deal of actual Rust behavior not fairly intimately tied to LLVM ? As far as I know it leaks various LLVM details and much of the documentation about various functions documents them as being little more than a thin wrapper to various LLVM internals.
I'd find that very surprising and interesting - I can't imagine which semantics could leak from LLVM into a language specification. Can you give some examples?
I'm not sure as to what capacity GCC has a similar instruction but I heard that LLVM's using of signed integers here is apparently nonstandard and what lead to Rust's decisions for vectors to be limited to a certain size: https://doc.rust-lang.org/nomicon/vec-alloc.html
What I really hope is that the Rust community doesn’t go out of its way to make this easier. Communicate and let value come back but there’s an significant amount of value in keeping a single backend relies on. CPython has done the Python community a lot of good by keeping one official compiler/tool chain (despite the great work done by projects like JPython/PyPy). The only way to do this properly, if desirable, is t…
If "progress" means "rapidly add more and more new features in each release", multiple implementations will slow things down. But that problem can be addressed with editions: at some point, if the project is a success, the gcc front end will be a feature-complete version of some Rust edition, plus enough extra features to build an older version of the Rust compiler. At that point, you have a better solution to the bootstrapping problem (how to get a Rust compiler when you only have a C compiler and you want to build everything from source and not trust some binary you download from somewhere).