Use ChildTyper in the validator about binaryen HOT 9 OPEN

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?

from binaryen.

I can look into it, sure.

from binaryen.

A problem that happens here is that ChildTyper seems to assume valid IR already. For example:

getHeapType() will assert if the type is unreachable, and getSignature() will assert if it is a non-signature reference type.

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.

from binaryen.

Since ChildTyper only checks types based on information that would be included in the binary, my expectation is that other properties, including whether we can even produce such information, would be checked by the validator before it calls into ChildTyper. Basically wherever we have a type annotation in the binary format, the validator will have to check that the type is valid before checking the child types more generally.

from binaryen.

It seems hard to split things out that way, I'm afraid. CallRef would need to see that the reference child is unreachable and therefore ignore it in ChildTyper. That is, it is valid for that child to be unreachable, so we can't just put a check before calling ChildTyper here. ChildTyper itself would need to do the check or at least I can't see a better way.

from binaryen.

I would expect that when validating a CallRef, the validator would only call into ChildTyper if the ref is a typed function reference. Why is it hard to split out that way?

from binaryen.

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 visitCallRef or such, that is, it is specific to each expression class. That means we can't do it in a more generic location which would have been a lot simpler/shorter.

from binaryen.

Ah, as an example for the first paragraph in the last comment, see StringEncode:

If the array is unreachable we still need to reach the last line that validates the i32 type of another child.

from binaryen.

Also, that would mean that the decision to call the ChildTyper must be done in visitCallRef or such, that is, it is specific to each expression class. That means we can't do it in a more generic location which would have been a lot simpler/shorter.

Yes, it would be an annoyingly large PR. An alternative might be to have ChildTyper detect when there's not enough information to type some children and fall back to some more general constraint only for those particular children. So in the example above, we could leave array unconstrained by still ensure that str and start have the correct types.

from binaryen.