5 ms·

Didn't really get it. Does it speed programs up, or allow better guessing or when borrow checking isn't actually violated? If the former, what kind of situation

• mjw1007 7y ago
  As I understand it, this is a proposal for formalising Rust's existing rules around memory safety and the borrow checker.
  • kd5bjo 7y ago
    Yes, and extending that model to unsafe code. It would make violations of the model have undefined results, which allows the compiler to make optimizations that assume the model is followed even in situations where that can’t be statically proved.
    • acqq 7y ago
      Hopefully the programmer will be informed whenever the compiler decides it can treat some code as "undefined"? Otherwise, it can be the source of bad results.
      • kd5bjo 7y ago
        In Rust, that’s more or less the meaning of the unsafe keyword. It marks code that does things the compiler can’t verify as correct, but it’s always been expected that unsafe code will maintain the invariants the Rust compiler uses. This is an attempt to formalize that general expectation.
      • cesarb 7y ago
        > Hopefully the programmer will be informed whenever the compiler decides it can treat some code as "undefined"? That's the wrong mental model. The compiler doesn't decide to treat some code as "undefined". Instead, the compiler assumes all code is not "undefined", and generates code according to that. The compiler might notice that the code is doing bad things, and warn the developer (or even return an error), but that's not guaranteed, since undefined behavior is generally things the compiler cannot easily check. For an example, Rust guarantees that no two mutable references can reference the same place at the same time, even in unsafe code. If a function receives a pair of mutable references, the compiler assumes that they do not overlap. If they in fact overlap, the code generated by the compiler might do the wrong thing.
        • acqq 7y ago
          I'm still on Linus' side: https://gcc.gnu.org/ml/gcc/2016-02/msg00381.html https://gcc.gnu.org/ml/gcc/2016-02/msg00381.html "The fact is, undefined compiler behavior is never a good idea. Not for serious projects. Performance doesn't come from occasional small and odd micro-optimizations. I care about performance a lot, and I actually look at generated code and do profiling etc. None of those three options have ever shown up as issues. But the incorrect code they generate? It has."
    • deleted 7y ago
      [deleted]
• Thorrez 7y ago
  I believe it's about creating a set of rules that when followed allow people to write `unsafe` code safely. It sounds like currently if you write `unsafe` code, the optimizer could introduce undefined behavior. This paper is creating a set of rules so that if your `unsafe` code follows those rules, there won't be undefined behavior.
  • cyphar 7y ago
    No, that's not quite right. Unsafe code written today does not by default have undefined behaviour -- if it did, it would be a useless tool. You can write programs using unsafe that have undefined behaviour (of course) but that's a bug in the code written. This paper isn't about that (nor is it necessarily about unsafe Rust). It's about compiler optimisations. Because Rust has very clear rules about references and borrows, the idea is to come up with a model for Rust code that allows for a particular optimisation (namely, to allow telling the compiler that two pointers do not alias -- do not refer to the same memory). Obviously unsafe code would need to make sure it obeys this new memory model, otherwise the code would be invoking undefined behaviour.
• maikklein_dev 7y ago
  If I understood it correctly, it just turns undefined behavior regarding aliasing into compiler errors
  • GolDDranks 7y ago
    No, it doesn't. There's a set of rules that are proven to have a set of desirable properties (from the viewpoint of compiler optimisations and programmer freedom, in a reasonable balance), and an accompanying interpreter that checks those rules, and turns undefined behaviour regarding aliasing into _runtime_ errors.
  • hyperman1 7y ago
    My take on this: There are certain properties all rust code should have. In safe rust, the compiler gives a mathematical proof this is so. In unsafe code, the compiler does not, but still assumes these properties are holding. The burden to make sure everything is correct falls on the shoulders of the programmers. But nobody knows exactly what these properties are. There is a big part known, but the edges are fuzzy. So unsafe code is required to follow rules nobody knows. This effort is part of the work to clarify the rules. If accepted, both the compiler and unsafe programmer knows how far they are allowed to go
    • littlestymaar 7y ago
      That's a really good summary, thank you.
  • notriddle 7y ago
    No, it doesn't. Stacked Borrows can only be checked at runtime. What it is, is a formal specification for something like an UB Sanitizer.
• cyphar 7y ago
  It's a paper about improving compiler optimisations by allowing Rust to tell LLVM whether two pointers will or will not alias (refer to the same block of memory). This aliasing information can provide some pretty significant speedups in a variety of common operations (for instance, memmove becomes a memcpy). I'm not a compiler developer so I unfortunately can't give you a specific example.