> 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?

Integer 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".

Pretty sure rust wraps on overflow, not saturates, but it's not hard to get that behavior from most C compilers if desired.

float 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

Rust also has different aliasing rules. Stricter than C for references, but more relaxed than C for raw pointers.

Clamping floats is interesting, but seems pretty niche.

Would have been nice to provide notice of your edits.

I'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.

Unfortunate timing.

> 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

To 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?

It 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.

For 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

The 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.

It 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.