6 ms·
The interesting thing to me is that this does not fully valid Rust code, e.g. not checking for borrow safety. Which would normally make no damn sense for a Rust
by lmkg 6y ago
The interesting thing to me is that this does not fully valid Rust code, e.g. not checking for borrow safety. Which would normally make no damn sense for a Rust compiler, but actually makes sense for what this particular project is trying to achieve.
This is not a compiler for developing Rust programs. This is a compiler to let platforms unsupported by Rust/LLVM build rust programs from source. So it takes a Rust program which already exists, assumes it can be compiled by rustc, and translates it to C so it can be handed off to your local compiler. Skipping the burrow checker probably lets this execute in environments which are more constrained than what rustc can fit into.
Of course there's a question of how much of Rust's safety survive translation into C. Certainly some. E.g. the emitted program would include bounds checks where not specifically elided in Rust, and references are statically guaranteed to be non-null before being lowered into pointers. But there could be gaps, especially in cases where Rust semantics mismatch with C in ways that LLVM hasn't exposed yet.
- rmdashrfstar 6y ago> But there could be gaps, especially in cases where Rust semantics mismatch with C in ways that LLVM hasn't exposed yet. Could you elaborate on what potential mismatches there currently are between the semantics of Rust and C? Where particularly do you think there might be issues/dragons hiding in the semantics of a translation?
- deleted 6y ago[deleted]
- gpm 6y agoInteger overflows (signed overflows defined to wrap or panic in rust, are undefined behavior in C). Float integer conversions (overflows are defined to saturate in rust, are undefined behavior in C). Maybe things like how pointer casts are treated in correct (but unsafe) rust vs C. Or similarly in transmute. Generally it wouldn't surprise me if rust was standardizing a memory model that was subtly different from C. I'm sure the list goes on, but "that sort of thing".
- tedunangst 6y agoPretty sure rust wraps on overflow, not saturates, but it's not hard to get that behavior from most C compilers if desired.
- pornel 6y agofloat to integer saturates in Rust. `99999.0 as u8` gives 255. `(char)99999.0` is UB in C and LLVM. Rust had to add explicit clamping code to float casts, because LLVM compiled nasal demons otherwise: https://github.com/rust-lang/rust/issues/10184 https://github.com/rust-lang/rust/issues/10184 Rust also has different aliasing rules. Stricter than C for references, but more relaxed than C for raw pointers.
- tedunangst 6y agoClamping floats is interesting, but seems pretty niche.
- tedunangst 6y agoWould have been nice to provide notice of your edits.
- gpm 6y agoI'm not sure if I edited at all, if I did edit it was within a minute or two of my original post. Edit: Now that I am coming back and reading this though I am going to make an edit, and like normal for substantive edits I'm going to mark it clearly... Edit2: Or I can't edit, so let's put it here: A better example than any of the above might be infinite loops, `while (true) {}` (or any similar loop without side effects) is undefined behavior in C, it's defined behavior in rust.
- tedunangst 6y agoUnfortunate timing.
- Blikkentrekker 6y ago> This is not a compiler for developing Rust programs. This is a compiler to let platforms unsupported by Rust/LLVM build rust programs from source. So it takes a Rust program which already exists, assumes it can be compiled by rustc, and translates it to C so it can be handed off to your local compiler. Skipping the burrow checker probably lets this execute in environments which are more constrained than what rustc can fit into. I would assume that borrow checking uses far less memory than the actual compilation after the compiler has proven the program to be in concordance with the borrow rules. It more so seems that it is something they did not bother to put too much effort into, as it wasn't necessary, than a legitimate way to reduce a compiler's memory footprint
- ris 6y agoTo me the question it raises is - does the rust borrow checker need to be part of the compiler or could it be separated into a standalone component? Is the borrow checker architecture-agnostic?
- twic 6y agoIt is architecture-agnostic. As currently implemented in rustc, it operates on an intermediate representation that has already had name resolution and some simplification done. As such, i think it would be rather hard to separate from the rest of the compiler.
- viraptor 6y agoFor the first one, definitely could be split. You can already run that part without code generation - https://doc.rust-lang.org/cargo/commands/cargo-check.html https://doc.rust-lang.org/cargo/commands/cargo-check.html
- MR4D 6y agoIt would be a nice addition in use similar to the auto-complete function - when you write a line of code that uses a value the breaks the tiles, it highlights the code right there. That alone would make rust a much easier language for newbies.
- tylerhou 6y agoThe borrow checker is actually fairly simple to implement, if you have the types. To deduce types, you need to parse the grammar, understand the control flow, and resolve any builtins. But you don’t need to emit any further representation.