Test breaking out of a try

[SoniEx2]

Tests that breaking out of a try resets the exception handler correctly.

See WebAssembly/wabt#2203

[rossberg]

Hm, I don't quite understand the focus of this test, it seems quite convoluted.

1. Why the outermost try, that never fires.
2. Why the block argument, that's immediately dropped.
3. How is the delegate relevant to the test?

[SoniEx2]

oh wait did we copy the wrong one

[SoniEx2]

so, with the correct test:

  (func (export "break-throw") (result i32)
    (try $outer (result i32)
      (do
        (try (result i32)
          (do
            (block $a
              (try (do (br $a)) (delegate $outer))
            )
            (call $throw)
            (i32.const 0)
          )
          (catch $e0 (i32.const 1))
        )
      )
      (catch $e0 (i32.const 2))
    )

the outer try is not supposed to fire. but the innermost try, the one with the br, does set up an exception handler that would delegate to the outer try. if the host doesn't handle the br correctly, it could forget to reset the correct handler, and when it calls $throw, it would fire the outer try (delegated from the innermost try).

the block is necessary because wasm2c has bugs. like not being able to br a try (wait you're supposed to be able to (try (do (br 0)) (delegate 0)) yeah?). but that's unrelated.

it's also important to call $throw so it uses the actual exception handler (due to how setjmp/longjmp work). but anyway.

[keithw]

In general it would be great to have test coverage of branching out of try and catch blocks (#210), including some simpler tests. This particular test seems valuable because it separates existing implementations that otherwise pass the current tests.

[aheejin]

+1 on adding tests for try + br. But the spec tests may not necessarily need to fire the wasm2c bug? If our purpose is testing a br within a try, this can be maybe as simple as

(module
  (tag $e0)
  ...
  (func (export "br-in-try")
    (block $l
      (try
        (do
          (br $l)
        )
        (catch_all)
      )
      (throw $e0)
    )
  )
  ...
)

(assert_return (invoke "br-in-try"))

Because if br doesn't work and we run into the throw, the function will throw.

[SoniEx2]

hmm what happened in CI?

[SoniEx2]

+1 on adding tests for try + br. But the spec tests may not necessarily need to fire the wasm2c bug? If our purpose is testing a br within a try, this can be maybe as simple as

(module
  (tag $e0)
  ...
  (func (export "br-in-try")
    (block $l
      (try
        (do
          (br $l)
        )
        (catch_all)
      )
      (throw $e0)
    )
  )
  ...
)

(assert_return (invoke "br-in-try"))

Because if br doesn't work and we run into the throw, the function will throw.

we disagree. we don't wanna test whether the br exits the try. tho we should probably test that too.

we wanna test whether the br updates the catch/delegate context correctly.

[aheejin]

hmm what happened in CI?

That means your test doesn't pass. Can you check locally and fix it? You can use test/core/run.py, or run the interpreter on individual files to get a better error message. The instruction is here: https://github.com/WebAssembly/exception-handling/tree/main/test/core

[aheejin]

+1 on adding tests for try + br. But the spec tests may not necessarily need to fire the wasm2c bug? If our purpose is testing a br within a try, this can be maybe as simple as

(module
  (tag $e0)
  ...
  (func (export "br-in-try")
    (block $l
      (try
        (do
          (br $l)
        )
        (catch_all)
      )
      (throw $e0)
    )
  )
  ...
)

(assert_return (invoke "br-in-try"))

Because if br doesn't work and we run into the throw, the function will throw.

we disagree. we don't wanna test whether the br exits the try. tho we should probably test that too.

we wanna test whether the br updates the catch/delegate context correctly.

I don't really understand what you mean by catch/delegate context here, and why what you are trying to test is different from my simple example. Can you elaborate? Also, if you'd like to add a complex test here, some comments on the test about what it is testing would help.

[SoniEx2]

it's testing whether the throw is going to the correct catch/delegate and not an unrelated catch/delegate.

for context: wasm2c returns 2.

[rossberg]

I agree that this test makes sense, but it seems a bit one-off. Can you perhaps extend it to a slightly more systematic bunch of tests for branching out of (different forms of) handlers?

[SoniEx2]

hmm, with call and throw variants?

[SoniEx2]

not sure what else to throw into these but this seems like a good starting point.

[rossberg]

Thanks, these look good to me. Can we keep them in try-catch.wast and try-delegate.wast, respectively, however? (The test suite is mostly structured around test files dedicated to individual instructions/constructs.)

[keithw]

Bump -- it would be nice if these tests (or something like them) landed. It looks like @SoniEx2 has responded to the feedback.

[aheejin]

Bump -- it would be nice if these tests (or something like them) landed. It looks like @SoniEx2 has responded to the feedback.

Sorry for the delays. But I think we can wait a little longer, given that #280 can change the spec?

[SoniEx2]

@aheejin does that break existing functionality? if not, then there's no reason to delay this - further tests can be added later.

[aheejin]

Sorry that this slipped from my notice and ended up not being merged for a long time. Can you fix the conflicts so we can merge this?

[SoniEx2]

oh. uh, is this still relevant? we don't know how the new EH system works, we just know we wrote these for the old system.

[aheejin]

Given that the old (Phase 3) proposal still has not been deprecated, I think it wouldn't hurt to merge this. By the way the legacy tests have moved into https://github.com/WebAssembly/exception-handling/tree/main/test/legacy/exceptions, so I think you should move these tests there too.

[SoniEx2]

oh good it just needed a rebase, nice

[keithw]

I'm a little confused that this only ended up touching the legacy tests. Are there new tests for try/br interactions in the current version of this proposal?

[aheejin]

I think we can write the corresponding tests for the new proposal too. Will add them if @SoniEx2 or anyone submits PRs for them.

[SoniEx2]

someone else will have to do it because we still haven't got around to figuring out how the new proposal works ^^'