commit 5da354f46ebeb8683fc2deab5bfe8109baa2b433
author Ömer Sinan Ağacan <omersa@google.com> Tue Feb 18 02:40:17 2025 -0800
committer Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> Tue Feb 18 02:40:17 2025 -0800
tree 0f1d529679fb628e6d313f5809d962cfb3c8174a
parent 26f08dd0364d1e7d5fac7ce3d273a89641c317c7

[dart2wasm] Don't compile catch blocks multiple times for JS exceptions

Currently when a Dart `catch` block can catch both Dart and JS
exceptions, we compile the `catch` body once in a Wasm `catch` block,
once in a Wasm `catch_all` block.

This is because a Dart exception needs to be caught in a `catch` with
the right tag, to be able to get the exception and stack trace values,
and JS exceptions need to be caught in `catch_all` and they come without
error values and stack traces.

With this CL we generate one Wasm block per Dart `catch` block. Wasm
`catch` and `catch_all` blocks only do type tests and jump to the right
Wasm `block` when a type test passes.

This allows using the same block for multiple Wasm `catch` and
`catch_all` blocks.

When jumping to the block for a Dart `catch` we pass the error value and
stack trace to the block. As before, when the caught exception is a JS
exception, we pass an empty `JavaScriptError` as the error value and the
call stack of the Dart `catch` as the stack trace.

We also replace Wasm `rethrow` instruction with `throw` when compiling
Dart `rethrow` statements. This change is necessary as the blocks for
Dart `catch` blocks are no longer enclosed by a Wasm `try`, and it also
makes it easier to switch to the new exception handling proposal, which
doesn't have a `rethrow` instruction.

This changes Wasm exceptions reported to the console in uncaught
exceptions, but when we switch to the new exception handling
instructions we will recover the stack traces, as `throw_ref` doesn't
update the stack trace of the error value.

Change-Id: I732c0192af158611d5f0a584182a48b0e13ff83a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/410321
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>