When looking at threads relared to poison vs no-poison mutex and whether non-poison should be the default, I read a comment suggesting poison isn't needed for abort-on-panic
That reminds me that, all the poison logic/bookkeeper in each poisoned mutex is essentially useless for abort-on-panic and can be removed to free up the space used by them.
So is there any reason we haven't do that yet? Is it because rust will support a c++-compatible external function that allows c/c++ unwinding in a rust function?
panic=abort doesn't abort immediately. It still runs arbitrary user code of the custom panic hook. The hook creates all kinds of re-entrancy complications. In this case the hook could try to access the same mutex (mutex can be reachable from a global variable).
If instead of poisoning, panic left the lock permanently locked, then it would be safe. Re-entrant access from the panic hook would deadlock in the worst case.
There is such feature (AFAIK it's called panic_immediate_abort), but it's mostly used on microcontrollers to avoid the code size bloat, and there we don't have std nor Mutex.
You probably mean my comment. As you can see in the replies, Mutex implements the suggested optimization since Rust 1.78. Unfortunately, to enjoy it currently you have to rely on -Zbuild-std (similarly to debug asserts inside std methods and function).