Unhandled tag should be proper runtime error

[titzer]

When I run the test:

(module
  (type $f1 (func))
  (type $c1 (cont $f1))
  (tag $e)
  (func $s (suspend $e))
  (elem declare func $s)
  (func (export "main")
    (resume $c1 (cont.new $c1 (ref.func $s)))
  )
)

(assert_trap (invoke "main") "unhandled tag")

The output is:

interpreter/wasm: uncaught exception Error(_, "unhandled tag")
Raised at Wasm__Error.Make.error in file "util/error.ml", line 6, characters 19-40
Called from Wasm__Eval.invoke in file "exec/eval.ml", line 1339, characters 15-23
Called from Wasm__Run.run_assertion in file "script/run.ml", line 518, characters 11-25
Called from Stdlib__List.iter in file "list.ml", line 110, characters 12-15
Called from Wasm__Run.run_script in file "script/run.ml" (inlined), line 619, characters 2-30
Called from Wasm__Run.run_quote_script in file "script/run.ml", line 624, characters 7-24
Re-raised at Wasm__Run.run_quote_script in file "script/run.ml", line 624, characters 58-67
Called from Wasm__Run.input_from in file "script/run.ml", line 104, characters 4-14
Called from Wasm__Run.input_sexpr_file in file "script/run.ml", line 148, characters 18-39
Re-raised at Wasm__Run.input_sexpr_file in file "script/run.ml", line 151, characters 27-36
Called from Wasm__Run.run_meta in file "script/run.ml", line 596, characters 16-50
Called from Stdlib__List.iter in file "list.ml", line 110, characters 12-15
Called from Wasm__Run.input_from in file "script/run.ml", line 104, characters 4-14
Called from Dune__exe__Wasm.(fun) in file "wasm.ml", line 67, characters 33-53
Called from Stdlib__List.iter in file "list.ml", line 110, characters 12-15
Called from Dune__exe__Wasm in file "wasm.ml", line 67, characters 4-72

I.e. this looks like an Ocaml crash, but it should be a runtime error as the test asserts.

[dhil]

We have the wast directive assert_suspension for asserting unhandled tags. Is your point that assert_trap should handle suspensions too, or do you mean it should gracefully exit (as opposed to throwing an unhandled exception)?

[rossberg]

Oh, indeed. Eval.Suspension should be handled in run.ml/input_from like all other.

[titzer]

Is your point that assert_trap should handle suspensions too,

Oh, indeed. Eval.Suspension should be handled in run.ml/input_from like all other.

Yes, if an unhandled suspension is a trap then I think assert_trap should be able to handle it. I think it's a bit cleaner to avoid introducing a new assertion mechanism (because consumers of .wast will have to implement it).

[rossberg]

It's not a trap, nor is an unhandled exception. They are simply that: unhandled exceptions/suspensions. The former was already reported, the latter wasn't.

[titzer]

Ok, I can accept that. Then I think an assert_suspension is fine.

[dhil]

This issue has been resolved in #93. Once #84 lands the fix will be available in main.

[dhil]

Fixed by #84.