Can we keep must progress optimizations around infinite loop in C++ while avoiding some surprising behavior?

I did look at it a bit - there’s a couple of related features already in - for MSVC there’s something that I think puts a nop after empty functions to address some limitation there, and there’s also a “trap on unreachable” that is enabled by default on MacOS and PS targets, I think - which sounds worse than it is - most unreachables get eliminated by optimizations anyway, so it’s not a huge cost.

Maybe trap-on-unreachable is what we should just enable by default/make the only behavior - if someone wants to measure/check it’s not too bad, which I don’t think it is.

When I was looking at this trying to address the zero-length-functions-break-DWARFv4 I think I got stuck in perfect-being-the-enemy-of-the-good - wanting to only put trap at the end of functions that don’t already end with some other unconditional branch (maybe even a call-to-noreturn? Not sure) and that was complicated because some targets (AMDGPU?) couldn’t readily emit a trap easily in their backends (something about needing certain properties on the function)… - I suspect throwing all that out and just doing “trap on unreachable” is probably fine.