I don't know what you mean. This is a compiler bug? Nobody claims that other compilers must also have the exact same bugs.
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!
> 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.
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.
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).
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.
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