It's surprising this bug went unnoticed for so long, but at least it's easy to fix, since it's not a bug with the type system itself; it's just a bug in the compiler. The compiler should always have been rejecting that code according to lifetime rules of Rust's type system, so the fix is to just make it reject the code, rather than having to change the fundamental rules of lifetimes.

▲

WiSaGaN 2 hours ago | parent | next [-]

It's fascinating that this kind of bug is exactly you can't really avoid even when rust is supposedly to guard against. Rust mitigated this problem a lot in practice, but you can never be certain because of issues like this in practice. This is similar that a math proof that's already been peer reviewed and accepted as truth, may still be possible to be wrong, although the chance is very small but it's not zero. Epseicially when the complexity gets higher.

▲

mav65 2 hours ago | parent | prev [-]

Not knowing anything about rust, the problem in these type of case is making it rejecting that bad code without also rejecting valid programs. But maybe this is indeed easy to fix, I don't know.

▲

bluGill 2 hours ago | parent | next [-]

There are no such valid programs. Proof by contradiction:

A valid program would be exploiting undefined behavior in rust, but rust has no undefined behavior. Thus such a program must not exist.

Now a program may appear to work before the fix, but it was never a valid Rust program.

	▲	afdbcreid an hour ago \| parent [-]
		I can't tell if you are sarcastic, but in case you are not: By Rice's theorem you cannot be sound and complete, i.e. accept all valid programs and reject all invalid ones. Most languages choose to be sound but not complete, i.e. reject all invalid programs but also some valid ones (C and C++ are the notable exception, although most languages have escape hatches). GP was saying that the fix might reject valid programs that compile today. This is true for some existing soundness bugs, but not necessarily for this one specifically.

▲

foldr an hour ago | parent | prev [-]

In this case the issue is that the compiler just isn't properly type checking the implicit call to the drop method that's inserted at the end of the nested block. AFAIK, no correct code should depend on the absence of that check.