Fuzzer: Add another stringview subtyping error message to ignore

[kripken]

Original text:

V8 errors on this, e.g. this was created:

 (rec
  (type $0 (sub (func (param nullref i32) (result (ref null $3)))))
  (type $1 (sub final $0 (func (param stringview_iter i32) (result (ref null $3)))))
 )

V8 says that subtyping is invalid.

Later PR focuses on ignoring a related message.

[tlively]

But this error is probably because a non-nullable reference is never a supertype of a nullable reference, right? If you change nullref to (ref none) in the first signature, does the problem go away?

[tlively]

I guess we haven't updated our parsers or binary writer, so we're probably still interpreting the stringview types as nullable.

[kripken]

Hmm, that snippet by itself does not error now, so it must have been related to the full testcase, which unfortunately I've not kept.

I reverted that part and added a separate fix here, which I'm fuzzing with now to try to reproduce the original issue with.

Can you elaborate on your last comment though? What parser/writer changes are we missing?

[tlively]

To match V8's new behavior, we would need to fix this code to use NonNullable instead of Nullable: https://github.com/WebAssembly/binaryen/blob/main/src/parser/parsers.h#L490-L498

We would need to make analogous fixes in the binary parser, the binary writer, and the printer. Without that, it's not surprising that round-tripping leads to disagreements with V8.

[kripken]

Ah yes, I see about the text format parsing. But that is just a text format issue? It can't explain the problem I saw.

And what do you mean by changes to the binary parsers? Are you saying to ignore a nullable annotation and treat it as non-nullable?

[kripken]

Here is a full testcase showing the issue:

(module
 (type $0 (func))
 (rec
  (type $1 (sub (func (param (ref null $13)) (result (ref struct)))))
  (type $2 (func (param (ref null $12) i64)))
  (type $3 (sub (func (param nullref f64) (result (ref null $8)))))
  (type $4 (sub (array (mut f32))))
  (type $5 (func (param i64 (ref null $9) (ref $4) arrayref) (result v128)))
  (type $6 (sub (array (mut f64))))
  (type $7 (func (param i64) (result (ref $3))))
  (type $8 (sub (array i8)))
  (type $9 (sub (array f64)))
  (type $10 (array (mut v128)))
  (type $11 (sub (array (mut (ref $2)))))
  (type $12 (sub final $3 (func (param stringview_wtf16 f64) (result (ref null $8)))))
  (type $13 (struct (field (mut f32)) (field (mut (ref $2))) (field (mut f32)) (field (ref $7)) (field (mut i32)) (field eqref)))
  (type $14 (sub (array (ref $10))))
 )
 (func $0
  (local $0 f32)
  (local $1 (ref $10))
  (local $2 (ref $10))
 )
)

[kripken]

IIUC you are saying that it's ok to consider string views supertypes of none, and we should work around that in parsing?

[tlively]

Are we sure that stringviews are no longer supertypes of none? I don't think that's what Jakob told us. He did tell us that the reference type shorthands are now interpreted to be non-nullable, though, so I suspect the fact that binaryen and V8 disagree about that is the only real issue. It's enough to explain the error in the test case above.

[kripken]

Wait, are the shorthands not a feature of the text format only? That might be what I am missing in your point.

Are we sure that stringviews are no longer supertypes of none?

It seems quite odd for them to be supertypes of none when they are not allowed to be nullable?

[tlively]

No, the shorthands exist in both the binary and text format.

Even with nullable references disallowed, we still have (ref none) <: (ref stringview). It's not useful in practice, but the fuzzer could certainly produce a program that relies on it.

[kripken]

I see. I'm not totally familiar with that part of the spec...

I'll land this trivial change (with proper PR title) as a followup to the previous one. Next week I can look into these shorthands, unless you want to do it.

[tlively]

I can fix the shorthands real fast.

[tlively]

#6578