3 ms·

I don't know what you mean. This is a compiler bug? Nobody claims that other compilers must also have the exact same bugs.

adastra22 3y ago
It is a compiler bug, yes.
- steveklabnik 3y ago
  Sorry, I was typing the way I talk again, this doesn't always come across well in text. Yes, thanks for making sure that's known.
nicklecompte 3y ago
It's really a bug in the design of Rust itself, not in the implementation of rustc: https://counterexamples.org/nearly-universal.html?highlight=Rust#nearly-universal-quantification https://counterexamples.org/nearly-universal.html?highlight=... The fix needs to happen at the level of type-theoretic computer science, not clever Rust programming. And in particular, an alternate implementation of Rust which fixes this bug would have a different type system than rustc, and arguably should be considered a separate dialect of Rust (at least unless rustc is updated accordingly).
- steveklabnik 3y ago
  I think in the same way that you are frustrated because people say "it's a compiler bug" too often, this feels like going in the other direction too much. The higher order bit, to me, is the "segfault in safe code means a bug" stance that the overall project takes. Soundness holes happen. Sometimes they take a while to transition away from. Arguing that the compiler faithfully implements an algorithm that causes bugs still means, from a higher perspective, that the compiler has a bug: they have chosen an inappropriate algorithm here. There is no specification of the specific implementation here. Rust could in fact (at least in theory, I am not an expert on this specific problem) transition to a different path here where the bug does not manifest. RFC 1214 is an example of the Rust Project successfully doing this, and hilariously enough, that situation is one of the things that led to this one!
  - nicklecompte 3y ago
    No, the issue is NOT that they chose "an inappropriate algorithm," they chose an inappropriate design of the language itself. From the link [some typos might be mine since I manually retyped some of the TeX symbols}: > With constrained types, there are two different ways to interpret a polymorphic type such as \forall a. C[a] -> String: > 1. "\forall a" really means "for all a" so the type above is invalid since C[a] is not a valid type for all a. > 2. "\forall a" really means "for all a for which the right hand side is valid," so the type above is valid, but it can only be used for a = Int. > ... > Option (2) requires slightly less annotation by the programmer, but it can be easy to lose track of the implicit constraints on a. Rust chooses this option, which led to a tricky bug. And if you go on to read what this tricky bug is, it does not involve any incorrect implementations or even any specific algorithm. It's conflicting requirements: the design of co/contravariance of lifetimes in Rust conflicts with the design of nearly-universal quantification over types: one or the other has to be changed in its core semantics, not merely patched with a better algorithm. ETA: My point is that an alternative compiler cannot simultaneously solve this "compiler bug" and be appropriately source-compatible with rustc. It seem like they would either have a different syntax for type quantification, or more stringent constraints on lifetimes.
    - steveklabnik 3y ago
      It's clear we're not going to see eye to eye here. "conflicting requirements" is a bug. It should be fixed. It may be hard to fix. It may take a long time to fix. That may mean "redesigning." Still a bug.
      - nicklecompte 3y ago
        I think we're not seeing "eye to eye" because you're not actually responding to my comment! You seem to be responding to something else. I said "it's really a bug in the design of Rust itself" and you agree. My point is that you said > Nobody claims that other compilers must also have the exact same bugs. And that's true! But it's not relevant. Most people say other compilers should have 1) the same underlying type theory as rustc 2) almost complete source-compatibility with rustc If, say, "rustd" satisfies 1) and 2), then it's guaranteed to have many of the same memory vulnerabilities as rustc. The only way to fix these vulnerabilities is to break 1) or 2), which is an awfully steep price.

adastra22 3y ago

It is a compiler bug, yes.

steveklabnik 3y ago
Sorry, I was typing the way I talk again, this doesn't always come across well in text. Yes, thanks for making sure that's known.

nicklecompte 3y ago

It's really a bug in the design of Rust itself, not in the implementation of rustc: https://counterexamples.org/nearly-universal.html?highlight=Rust#nearly-universal-quantification https://counterexamples.org/nearly-universal.html?highlight=... The fix needs to happen at the level of type-theoretic computer science, not clever Rust programming. And in particular, an alternate implementation of Rust which fixes this bug would have a different type system than rustc, and arguably should be considered a separate dialect of Rust (at least unless rustc is updated accordingly).

steveklabnik 3y ago
I think in the same way that you are frustrated because people say "it's a compiler bug" too often, this feels like going in the other direction too much. The higher order bit, to me, is the "segfault in safe code means a bug" stance that the overall project takes. Soundness holes happen. Sometimes they take a while to transition away from. Arguing that the compiler faithfully implements an algorithm that causes bugs still means, from a higher perspective, that the compiler has a bug: they have chosen an inappropriate algorithm here. There is no specification of the specific implementation here. Rust could in fact (at least in theory, I am not an expert on this specific problem) transition to a different path here where the bug does not manifest. RFC 1214 is an example of the Rust Project successfully doing this, and hilariously enough, that situation is one of the things that led to this one!
- nicklecompte 3y ago
  No, the issue is NOT that they chose "an inappropriate algorithm," they chose an inappropriate design of the language itself. From the link [some typos might be mine since I manually retyped some of the TeX symbols}: > With constrained types, there are two different ways to interpret a polymorphic type such as \forall a. C[a] -> String: > 1. "\forall a" really means "for all a" so the type above is invalid since C[a] is not a valid type for all a. > 2. "\forall a" really means "for all a for which the right hand side is valid," so the type above is valid, but it can only be used for a = Int. > ... > Option (2) requires slightly less annotation by the programmer, but it can be easy to lose track of the implicit constraints on a. Rust chooses this option, which led to a tricky bug. And if you go on to read what this tricky bug is, it does not involve any incorrect implementations or even any specific algorithm. It's conflicting requirements: the design of co/contravariance of lifetimes in Rust conflicts with the design of nearly-universal quantification over types: one or the other has to be changed in its core semantics, not merely patched with a better algorithm. ETA: My point is that an alternative compiler cannot simultaneously solve this "compiler bug" and be appropriately source-compatible with rustc. It seem like they would either have a different syntax for type quantification, or more stringent constraints on lifetimes.
  - steveklabnik 3y ago
    It's clear we're not going to see eye to eye here. "conflicting requirements" is a bug. It should be fixed. It may be hard to fix. It may take a long time to fix. That may mean "redesigning." Still a bug.
    - nicklecompte 3y ago
      I think we're not seeing "eye to eye" because you're not actually responding to my comment! You seem to be responding to something else. I said "it's really a bug in the design of Rust itself" and you agree. My point is that you said > Nobody claims that other compilers must also have the exact same bugs. And that's true! But it's not relevant. Most people say other compilers should have 1) the same underlying type theory as rustc 2) almost complete source-compatibility with rustc If, say, "rustd" satisfies 1) and 2), then it's guaranteed to have many of the same memory vulnerabilities as rustc. The only way to fix these vulnerabilities is to break 1) or 2), which is an awfully steep price.