Say we have the file repro.wat with an $invalid function, which doesn't match it's return signature, and a following valid function
with a select instruction:
```
(module
(func $invalid (result i32))
(func $normal (local i32)
i32.const 1
i32.const 2
i32.const 3
select
local.set 0
)
)
``` 
Trying to build it...
```
$ wat2wasm repro.wat
repro.wat:2:16: error: type mismatch in implicit return, expected [i32] but got []
(func $invalid (result i32))
               ^
repro.wat:8:1: error: type mismatch at end of function, expected [] but got [i32]
local.set 0
^^^^^^^^^
```
...gives an error in the valid function. Let's force the build with:
```
$ wat2wasm repro.wat --no-check
```
Now we have an invalid repro.wasm, and validating it...
```
$ wasm-validate repro.wasm
repro.wasm:000001b: error: type mismatch in implicit return, expected [i32] but got []
repro.wasm:000002a: error: type mismatch at end of function, expected [] but got [i32]
```
again gives an error in the valid function.
If you comment out the $invalid function:
```
(;(func $invalid (result i32));)
```
The remaining $normal function builds and validates successfully.

The errors seem to show up after `select` instructions, at the end of the function in version 1.0.33. In 1.0.27 it's a bit different, the errors seem to show up for the instruction immediately after the `select`. Keep in mind this bug that may account for some of the off-by-ones https://github.com/WebAssembly/wabt/issues/1217

Ideally, wasm-validate would be able to re-synchronise itself after errors like this, or abort immediately after an unrecoverable error (with a message saying as such and where validation stopped), so users don't think there are more issues than there actually are.
`wasm-validate` gives false positive errors that occur after a true positive.
This is a GitHub Issue
repo:wabt
owner:WebAssembly
Title : `wasm-validate` gives false positive errors that occur after a true positive.
Issue date:

--- start body ---
Say we have the file repro.wat with an $invalid function, which doesn't match it's return signature, and a following valid function
with a select instruction:
```
(module
(func $invalid (result i32))
(func $normal (local i32)
i32.const 1
i32.const 2
i32.const 3
select
local.set 0
)
)
``` 
Trying to build it...
```
$ wat2wasm repro.wat
repro.wat:2:16: error: type mismatch in implicit return, expected [i32] but got []
(func $invalid (result i32))
               ^
repro.wat:8:1: error: type mismatch at end of function, expected [] but got [i32]
local.set 0
^^^^^^^^^
```
...gives an error in the valid function. Let's force the build with:
```
$ wat2wasm repro.wat --no-check
```
Now we have an invalid repro.wasm, and validating it...
```
$ wasm-validate repro.wasm
repro.wasm:000001b: error: type mismatch in implicit return, expected [i32] but got []
repro.wasm:000002a: error: type mismatch at end of function, expected [] but got [i32]
```
again gives an error in the valid function.
If you comment out the $invalid function:
```
(;(func $invalid (result i32));)
```
The remaining $normal function builds and validates successfully.

The errors seem to show up after `select` instructions, at the end of the function in version 1.0.33. In 1.0.27 it's a bit different, the errors seem to show up for the instruction immediately after the `select`. Keep in mind this bug that may account for some of the off-by-ones https://github.com/WebAssembly/wabt/issues/1217

Ideally, wasm-validate would be able to re-synchronise itself after errors like this, or abort immediately after an unrecoverable error (with a message saying as such and where validation stopped), so users don't think there are more issues than there actually are.
--- end body ---

The issue describes a problem with the `wasm-validate` tool in the WABT (WebAssembly Binary Toolkit) where it reports false positive errors in valid functions that follow an invalid function. This can lead to confusion for users as the validation process does not properly handle errors, causing it to report issues in valid code after encountering an invalid function. This is not a security vulnerability but rather a bug in the validation logic.