This is a case D97677 missed. When taking out remaining BBs that are
reachable from already-taken-out exceptions (because they are not
subexcptions but unwind destinations), I assumed the remaining BBs are
not EH pads, but they can be. For example,
try { try { throw 0; } catch (int) { // (a) } } catch (int) { // (b) } try { foo(); } catch (int) { // (c) }
In this code, (b) is the unwind destination of (a) so its exception is
taken out of (a)'s exception, But even though the next try-catch is not
inside the first two-level try-catches, because the first try always
throws, its continuation BB is unreachable and the whole rest of the
function is dominated by EH pad (a), including EH pad (c). So after we
take out of (b)'s exception out of (a)'s, we also need to take out (c)'s
exception out of (a)'s, because (c) is reachable from (b).
This adds one more step before what we did for remaining BBs in D97677;
it traverses EH pads first to take subexceptions out of their incorrect
parent exception. It's the same thing as D97677, but because we can do
this before we add BBs to exceptions' sets, we don't need to fix sets
and only need to fix parent exception pointers.
Other changes are variable name changes (I changed WE -> SrcWE,
UnwindWE -> DstWE for clarity), some comment changes, and a drive-by
fix in a bug in a LLVM_DEBUG print statement.
Fixes https://github.com/emscripten-core/emscripten/issues/13588.
I don't see any CHECKs here. I guess the test is just to ensure there are no assert failures?