Tail call + exception handling

[thibaudmichaud]

return_call and related instructions from the tail-call proposal (now phase 4) unwind the current frame before calling the target. So if the return_call is enclosed by a try block, I expect that any exception thrown by the callee cannot be caught by the try block:

try
  return_call $fn
catch_all
  ;; Unreachable, this frame is gone so the exception is "rethrown" to the caller.
end

Does this match everyone's expectations? Should we add some spec text and tests to cover this case? Are there other ambiguous cases with tail-call+EH?

[rossberg]

Yes, this is what's intended (and the only meaningful semantics). AFAICS, the spec doesn't need to say anything extra, it directly follows from how tail invocation is specified and the fact that a try handler is just another thing on the stack that is not an activation frame.

Of course, we should have tests for this.

[vouillon]

I'm wondering whether it would not be better to disallow tail calls within a try block. This is really error-prone. I was bitten by this (ocaml-wasm/wasm_of_ocaml@e7f3e63) and I'm not the only one. See OCamlPro/wasocaml@883f1e0 or WebAssembly/binaryen#6436. And it does not seem to me that a compiler can really take advantage of this to generate significantly better code.

[aheejin]

I don't want to put extra efforts on the old spec at this point, but would it be possible to change the spec so throw inside a return_call will be caught by the surrounding try? For example, when $throw is a function that throws,

try
  return_call $throw
catch_all
  ...
end

The toolchain cannot make an assumption that this code block does not throw because of the return_call. If it were not for that return_call toolchain can assume the code block does not throw and optimize accordingly. Also this seems to be surprising to many people (including me when I learned about it).

[tlively]

FWIW all this applies equally well to try_table.

I can see that producers would not want to do tail call optimization (i.e. replace call + return with return_call) inside a try block, and I can see that the behavior of return_call inside a try/try_table is counterintuitive, but I really don't see a viable alternative semantics. What would it mean to keep the try_table surrounding the return_call? Where would it jump to if the call threw an exception? The surrounding call frame and all of its labels should already have been popped before the call takes place, otherwise return_call is no different from a normal call.

Simply disallowing return_call inside try_table does not have the same semantic issues, but it also seems like an unnecessary restriction. We generally don't disallow things that would be safe from the engine perspective just because they are easy to hold incorrectly.

It can also be totally reasonable to use a return_call inside a try_table if the producer knows that the called function cannot possibly throw a handled exception.

[rossberg]

What @tlively said. There are plenty of things that are error-prone on the level of assembly. Wasm validation has never been for the sake of guarding producers against mistakes but solely for protecting engines. And for engines, such a check would just be extra work (besides complicating the language).