Fix a panic when validating return_call after end (#1641)

This commit fixes a mistake that was introduced in #1587 which was first
released as 1.210.0 as part of `wasm-tools`. In #1587 control flow was
restructured in the validator to expose an out-of-bounds access of
`self.control` when a function has instructions after the final `end`
instruction. The fix in this commit is to apply the same logic as
`check_return` which is to explicitly check for the length of the
`control` stack and return an error.

This bug comes from how instructions-after-`end` are detected in the
validator. Notably this erroneous condition is checked when the
functions reaches EOF, not when the control stack is emptied. This is to
avoid checking at all instructions that the control stack has a length
greater than one and to instead defer that check to only instructions
that need it. This susprising behavior, though, ended up leading to this
bug.

Author: alexcrichton

crates/wasmparser/src/validator/operators.rs

@@ -904,6 +904,9 @@ where
     /// Check that the given type has the same result types as the current
     /// function's results.
     fn check_func_type_same_results(&self, callee_ty: &FuncType) -> Result<()> {
+        if self.control.is_empty() {
+            return Err(self.err_beyond_end(self.offset));
+        }
         let caller_rets = self.results(self.control[0].block_type)?;
         if callee_ty.results().len() != caller_rets.len()
             || !caller_rets

tests/local/tail-call-after-end.wast

@@ -0,0 +1,8 @@
+(assert_invalid
+  (module
+    (func
+      end
+      return_call 0
+    )
+  )
+  "operators remaining after end of function")

tests/snapshots/local/tail-call-after-end.wast.json

@@ -0,0 +1,12 @@
+{
+  "source_filename": "tests/local/tail-call-after-end.wast",
+  "commands": [
+    {
+      "type": "assert_invalid",
+      "line": 2,
+      "filename": "tail-call-after-end.0.wasm",
+      "text": "operators remaining after end of function",
+      "module_type": "binary"
+    }
+  ]
+}