Even if you are no_std, core has tons of APIs like unwrap(), index slicing, etc. that can panic if you violate the preconditions. It's not practical to grep for all of them.
No-panic looks nifty: it appears to be reliable, which is great. I wish there was an easy way to automatically apply this annotation to every single function in a given file or crate.
https://doc.rust-lang.org/beta/src/std/io/stdio.rs.html#674-...
The implementation calls indeed a panicking API, OnceLock::get_or_init:
https://doc.rust-lang.org/beta/std/sync/struct.OnceLock.html...
But it only panicks if it is being used in a wrong way, which it isn't. The usage is contained within the implementation of std::io::stdout, so it's an implementation detail.
It's a shame that there are no better ways to eliminate panics in case they are impossible to trigger. The article shows some tricks, but I think the language is missing still some expressability around this, and the stdlib should also thrive harder to actually get rid of hard-to-optimize links to panic runtime in case of APIs that don't actually panic.
The main reason getting panic-free stdout is hard, is that the STDOUT initializers both call allocating constructors, and LineWriter doesn't have non-allocating constructors.
Solving this elegantly seems hard.
I 100% agree with your last paragraph. I would love if the language and stdlib made it easier to make panic-free binaries.