42bc23de2b
This adds a test which I suspected would fail, but luckily it doesn't. The idea is to catch a proper wasm exception in JS, then construct a new exception, but set the catched exception as the prototype. My suspicion was that we would still handle that new exception like a wasm exception, since the `WasmExceptionGetTag` and `WasmExceptionGetValues` runtime functions to a standard property lookup, which includes a prototype walk. Interestingly, the prototype walk is already skipped automatically when loading private symbols, so the implementation already supports this case correctly. Let's still add this test to have coverage for this case. R=jkummerow@chromium.org CC=aheejin@chromium.org Bug: v8:8091 Change-Id: Idf9944cf47f96cca38e9678e9200bf03a39ea126 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2167438 Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67391} |
||
---|---|---|
.. | ||
benchmarks | ||
cctest | ||
common | ||
debugger | ||
debugging | ||
fuzzer | ||
inspector | ||
intl | ||
js-perf-test | ||
memory | ||
message | ||
mjsunit | ||
mkgrokdump | ||
mozilla | ||
test262 | ||
torque | ||
unittests | ||
wasm-api-tests | ||
wasm-js | ||
wasm-spec-tests | ||
webkit | ||
BUILD.gn | ||
OWNERS |