rustig

eck, then a program using both of them passes the check. This is the essential property that makes typechecking predictable enough to produce useful error messages. This binary analysis tool operates on the whole program. Turning optimizations on and off will cause the tool to switch from reporting "ok" to reporting false positives. Pretending that a tool like this is a replacement for a typechecker amounts to grossly negligent software engineering. Panics are an ugly leftover from the bad old days before Rust had nice monad-like "?" syntax for Result<T,E> error-handling. It's time for unrestricted panic to sunset. The Rust community has waited too long to do this, which is why it will be painful. Waiting longer will only make it even more painful. > panics are catch-able False. Unwinding panics runs drop handlers; if one of these drop handlers itself panics, Rust just sort of throws its hands up in the air and aborts the process no matter what: > Given that a panic! will call drop() as it unwinds, any panic! in a drop() implementation will likely abort. https://doc.rust-lang.org/std/ops/trait.Drop.html#panics The panic mess is full of nasty ill-defined edge cases like this. It's gotta go.

ays and it's not a big deal. Obviously it is critical for Linux, but because it's relevant only to the minority of Rust users, it doesn't make sense to include it in rustc itself: it's exactly the kind of situation where external tooling is the good option. [1] https://github.com/Technolution/rustig