I agree that unsafe isn’t evil and shouldn’t be “avoided at all costs”, especially when using unsafe could be eg eliminated by the compiler (very common usage, actually!) or give you far superior codegen or code complexity.

But test coverage of unsafe blocks is not a meaningful metric. The best automated solution is standalone Miri runners exercising all branches of the code (via tests or otherwise) because tests on their own won’t catch things like out of counts reads or heap corruption unless you get lucky.

Penalizing the stdlib for using `unsafe` would be extremely counter-productive, because you could almost trivially remove all `unsafe` in the stdlib by moving those "unsafe" operations into codegen emitted by compiler (which is essentially how every other memory-safe language under the sun works, including Java, Python, etc.). Voila, no more unsafe in the stdlib... except now you have exactly the same code existing in a form that's both harder to inspect and doesn't benefit from the bevy of tools that exist to audit unsafe blocks in regular Rust code, meaning you have an implementation that's less safe in practice. And outside of the code contained in the stdlib, the majority of Rust crates don't use `unsafe` at all (exact proportion varying by domain; e.g. embedded use cases will probably all use `unsafe` somewhere).