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!
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.
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.
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.
FWIW C and C++ also have plenty of compiler-specific and language errata due to unsoundness issues in the spec / implementation bugs following the spec. I don't really follow how an alternate Rust compiler would solve this since a language errata needs to be fixed at the language level & would impact all conforming compilers unless this alternate Rust compiler basically forked the language, in which case the Rust trademark is good as it lets people disambiguate between the forks.
If it's a design issue, the Rust team is doing pretty good on that front I think in terms of exploring new ways of represting the type system (e.g. Polonius & the Trait solver work that's moving forward).
Also, even if it somehow a new compiler somehow improved soundness without forking the language, especially for a language as complex as Rust, at best you're just picking an alternate set of bugs. AFAICT the Rust team follows best practices in terms of developing the code & managing the people working on it, so it's hard to imagine an alternate compiler team would outperform their progress until the Rust project itself stagnates. Also, any successful fork would likely start with rustc as the basis anyway (the struggles and slow-going GCC is having reimplementing Rust within GCC should exemplify why a separate frontend isn't helpful).
This is still not a conflicting requirement. Rust relies on implicit bounds, that is said in the linked document, and the "universal" quantification there is not really universal, it in fact has a requirement. It's not present in the syntax, but it's present in the type system. The algorithm in the compiler loses that requirement and fails to reject invalid programs.
Rust has many cases when it introduces implicit type-level properties, another one is async-fns with its lifetimes and marker-traits such as Send.
> It's not present in the syntax, but it's present in the type system.
The trickiness of the bug is that the design of contravariance means the constraint is actually not present in the type system even though it should be. See this other comment I wrote: https://news.ycombinator.com/item?id=39448909
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!