The body of a @finally needs to be executed on both exceptional and
non-exceptional paths. On landingpad platforms, this is straightforward:
the @finally body is emitted as a normal (non-exceptional) cleanup,
and then a catch-all is emitted which branches to that cleanup (the
cleanup has code to conditionally re-throw based on a flag which is set
by the catch-all).
Unfortunately, we can't use the same approach for MSVC exceptions, where
the catch-all will be emitted as a catchpad. We can't just branch to the
cleanup from within the catchpad, since we can only exit it via a
catchret, at which point the exception is destroyed and we can't
rethrow. We could potentially emit the finally body inside the catchpad
and have the normal cleanup path somehow branch into it, but that would
require some new IR construct that could branch into a catchpad.
Instead, after discussing it with Reid Kleckner, we decided that
frontend outlining was the best approach, similar to how SEH __finally
works today. We decided to use CapturedStmt (which was also suggested by
Reid) rather than CaptureFinder (which is what __finally uses) since
the latter doesn't handle a lot of cases we care about, e.g. self
accesses, property accesses, block captures, etc. Extending
CaptureFinder to handle those additional cases proved unwieldy, whereas
CapturedStmt already took care of all of those. In theory __finally
could also be moved over to CapturedStmt, which would remove some
existing limitations (e.g. the inability to capture this), although
CaptureFinder would still be needed for SEH filters.
The one case supported by @finally but not CapturedStmt (or
CaptureFinder for that matter) is arbitrary control flow out of the
@finally, e.g. having a return statement inside a @finally. We can
add that support as a follow-up, but in practice we've found it to be
used very rarely anyway.