-
Notifications
You must be signed in to change notification settings - Fork 717
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use ChildTyper in the validator #6613
Comments
Improving the validator this way would let us re-enable the unreached-invalid.wast spec test. @kripken, were you interested in taking a look at this? |
I can look into it, sure. |
A problem that happens here is that ChildTyper seems to assume valid IR already. For example: Lines 781 to 784 in 1079a9e
I'm not sure offhand what kind of API change would make the most sense here, but doing that as a first step is necessary I think. |
Since |
It seems hard to split things out that way, I'm afraid. |
I would expect that when validating a |
I guess nothing after it needs to be validated if the ref is not a signature, but I'm not sure that's the case elsewhere - in general we may have one child be unreachable and need to ignore it, but not another. Also, that would mean that the decision to call the ChildTyper must be done in |
Ah, as an example for the first paragraph in the last comment, see StringEncode: Lines 987 to 995 in 1079a9e
If the array is unreachable we still need to reach the last line that validates the i32 type of another child. |
Yes, it would be an annoyingly large PR. An alternative might be to have |
The validator uses a large amount of code to check that child expressions have the correct types. Writing this code is a very manual process, and bugs are hard to catch because they manifest as the validator being overly permissive. We can delete a large amount of validator code and make it easier to get full validator coverage by using the new
ChildTyper
utility from the validator. We should also add more comprehensive validation tests, ideally as upstream spec tests (see #6612)The text was updated successfully, but these errors were encountered: