31–40 of 179 posts
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.
Earlier quoted context omitted.
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?
For instance `std::ptr::offset` which is apparently a trivial wrapper around some LLVM internal: https://llvm.org/docs/LangRef.html#getelementptr-instruction 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-…
I only bring it up because it pretty drastically harms readability (for me at least, and to a degree I frankly find surprising). Just thought you may want to know.
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…
>> The only way to do this properly, if desirable, is to make GCC an official backend of the main frontend. That will defocus some progress that happens with LLVM (every feature has to be implemented on both backends) and can make dev lives hard (eg “oh this problem comes up with GCC so use the LLVM backend “) No. The correct way is to create a Rust language specification that describes what the correct behavior is.…
Earlier quoted context omitted.
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?
For instance `std::ptr::offset` which is apparently a trivial wrapper around some LLVM internal: https://llvm.org/docs/LangRef.html#getelementptr-instruction 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-…
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?
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?)
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.
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…
Earlier quoted context omitted.
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?
For instance `std::ptr::offset` which is apparently a trivial wrapper around some LLVM internal: https://llvm.org/docs/LangRef.html#getelementptr-instruction 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-…
And using signed integers is unusual yes, but again all backends (obviously) also support signed integers.
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.
That being said, there's also cases where Rust does not have LLVM semantics, and that can cause bugs. Some famous examples being the loop optimization miscompilation, and &mut T currently not being marked noalias.
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?
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.
IMHO, "great deal" is overemphasizing it. There are some things, yes, but they are mostly smaller, more niche details that are even probably things we'd choose ourselves in many cases. That being said, there's also cases where Rust does not have LLVM semantics, and that can cause bugs. Some famous examples being the loop optimization miscompilation, and &mut T currently not being marked noalias.
I don't think that's a case where Rust "doesn't have LLVM semantics" since the miscompilation was reproduced in standard C. Rather that rust is actively and ubiquitously leveraging otherwise rarely-exercised LLVM features, revealing a bunch of bugs (either leftovers or breakages) in them.