A finally that returns, breaks or holds a try works on the exceptional path on Windows

[ASDAlexander77]

Fixes two shapes that crashed tslang --emit=jit with 0xC0000005 in function(ts::Win32ExceptionPass) under every -mm:

function f(pre: string) { let s = pre + "1"; try { h(); } finally { return s; } }   // now prints p1
function g(pre: string) { let s = pre + "2"; try { h(); } finally { try { h(); } catch { print("in " + s); } finally { print("inner " + s); } } return s; }
// main: try { g("p"); } catch { print("c"); }   → in p2 / inner p2 / c

Cause

On Windows, the copy of a finally that runs on the exceptional path is a cleanup funclet, and a cleanup funclet can't do what these finallys need:

• It can't return to normal flow. The return branched out of the cleanup region, so the pass never found a resume to end it. The region's end stayed null, and the pass dereferenced it.
• It can't hold pads of its own. TryOpLowering tagged the inner try's pads as top-level, so the scan closed the cleanup region early, again with no end. Nesting them properly would not have been enough either: under the MSVC personality, LLVM gives no EH state to a pad inside a cleanuppad. The inner throw would then terminate the process (CRT abort dialog).

Fix

• TryOpLowering: when a finally holds a return, a break/continue out of the try, or a try, its exceptional-path copy is entered through a catch-all pad instead.
  • A return or jump in that copy ends the catch first, which gives a catchret, and the exception is swallowed.
  • A copy that runs to its end finishes the way a cleanup does: end-catch, then resume.
  • The finally's pad now gets an id. Tries in that copy, and only that copy, are tagged as nested in it.
• Win32ExceptionPass:
  • A catch region that ends in resume becomes a rethrow from inside the funclet. It goes to the handler the region unwinds to, or to the caller.
  • A region with no end is now reported with report_fatal_error instead of crashing on a null dereference.

Tests

New 00try_finally_funclet.ts (compile + JIT + TSLANG_CORPUS gc/rc/none) covers:

• a return in a finally, with and without a throw
• a try in a finally whose exception carries on out
• a try in a finally inside an enclosing try that catches
• a return in a finally inside a try that catches
• a break in a finally

All of these also pass with --opt=false and as AOT executables. Full ctest -C Release -j 8 --timeout 300 was green on the branch base, 0b6859c (4138/4138).

main has since gained #596 and #597. They merge cleanly with this branch, but I haven't run the merged result locally, so CI covers that.

The try-in-finally test passes the string as a parameter instead of an owned local. An owned local in a function that an exception leaves through a try/finally was a known rc leak (still open after #595). The ownership-verifier sweep would flag it, and #596 may have closed it.

Not changed

A region that leaves on only some paths, like finally { if (c) return s; } or catch { if (c) return s; ... } (the latter is already broken on main), still breaks. The pass's scan assumes each region has a single exit. That needs CFG-based region membership, so it's left for a follow-up.

🤖 Generated with Claude Code