Return arity not checked

[sunfishcode]

On the stack branch, the following code is accepted:

  (func $bar
     i32.const 0
     return
  )

however the following code is rejected:

  (func $bar
     i32.const 0
     br 1 0
  )

This makes return not interchangeable with a branch to the control-stack top. And, it's inconsistent with the spirit of the explicit-drop change, wherein excess values are not permitted to be left on the stack.

[sunfishcode]

Ah, I'm mistaken here. The br version of return would be br 0 0 here, because the arity of the function is 0. It's still surprising in this context that br 0 0 implicitly drops excess values on the stack, however this is consistent with the existing design.

[rossberg]

Yes, I'm aware of the difference between br and return we introduced, and I don't like it either. However, the only way I can see this being reestablished is by keeping the arities on return.

I don't understand your point about "inconsistency with the explicit-drop change". That didn't affect that control transfer constructs like br, return, or unreachable still discard the (rest of the) operand stack.

@sunfishcode Could you clarify that your proposal for explicit-drop retains the discarding of excess values by a break operator? So that the current block semantics could be emulated with (block-old (i32.const 1) (i32.const 2)) == (block-new (i32.const 1) (i32.const 2) (br 1 0)). Break unwinds right?

Also this might be a simple example to ponder, where adding multiple value support would necessarily leave values on the stack. I see various discussions assuming that the number of values on the stack at a block fall-through can be the number of values returned by the block, but this does not hold in this example and drop can not fix this:

block arity=1
 call $give_me_i32_i32
 i32.neg
end