I remember that one. It came in just under the deadline and it would have been pretty bad if that got into 1.0.
The resolution of this not only had a notable effect on how Rust thought about memory safety (in particular, that leaking memory could not be considered unsafe as it's always possible to construct a leak using safe Rust if you have access to Rc, and as a result `std::mem::forget()` was changed from unsafe to safe), but also informed the way we used RAII going forward, as the fundamental unsafety was due to the use of an RAII value as a token representing external computation and was not itself used in order to perform that computation, which meant leaking the token didn't prevent computation from happening. In all other known cases of RAII, leaking the value is safe because without the value, you can't access the protected resources, but in this case the token represented a thread and the thread of course would continue to run after you leak the token. As a takeaway from this lesson, you can't use tokens to represent external processes, and probably shouldn't use them to represent e.g. hardware that needs to be put back into a known state when the token is dropped unless you have a mutex in there as well (which would cause deadlock if you drop the token and then reuse the resource, rather than sending bad commands that break the hardware). Instead, any time leaking the token would cause unsafety, you need to structure your code to use explicit scopes instead, such that the library can clean up at the end of the scope.
0. http://cglab.ca/~abeinges/blah/everyone-poops/