[Strings] Make string a subtype of ext, not any #7373

kripken · 2025-03-13T23:51:44Z

StringLowering converts strings to externs, which makes sense as we lower
stringrefs to imported JS strings. For the reverse transform it is convenient
to just have strings be subtypes of ext, see #7370 - that makes it simple to
switch stringref to externref and vice versa.

tlively · 2025-03-14T00:14:56Z

src/wasm/wasm-type.cpp

+      // Bottom types already handled (including string as the switch value,
+      // which implies the other value is bottom, which again would have been
+      // handled).


I don't understand the addition to this comment. string isn't a bottom type, so why is it included in the bottom types already having been handled?

Lines 399-400 swap to get the lower type as a. If a is string, then b is higher than a, which means (since string is the last of the non-bottom types in the list) that b is a bottom type. But we already handled bottom types before on 392-396.

Right, but I don't get that from reading the comment. Is there something special about string here that doesn't also apply to other types?

Just that strings are at the end (right before all the bottom types). I can add that to the comment.

Comment improved.

tlively · 2025-03-14T00:16:07Z

src/wasm/wasm-type.cpp

@@ -949,8 +956,9 @@ std::optional<HeapType> HeapType::getSuperType() const {
      case none:
      case exn:
      case noexn:
-      case string:


Yikes! This doesn't look like it was correct before, since it should have returned any. Do you know how this wasn't caught by tests?

The test was just wrong, but it agreed with the code 😄

See line 1683 in the gtest modified in this PR.

tlively · 2025-03-14T00:18:55Z

test/lit/exec/strings.wast

-    (any.convert_extern
-      (extern.convert_any
-        (string.const "string")


It might still be useful to test any.convert_extern of a string.

I don't follow - convert it from what to what?

In the new model a string is an externref like a JS object is an externref: it doesn't have a wasm representation under any.

any.convert_extern and extern.convert_any are infallible; all any and extern values, including strings, can be converted to the other representation.

But what is the "other representation" of string? I.e. what are you saying that any.convert_extern of a string should return - what actual type?

It's an anyref. There's no more specific type and trying to cast it to anything else will fail.

Sure, I guess we can leave it for later. I need to update the interpretation of casts to handle exact types at some point anyway.

The fuzzer hits this, so we do need to resolve the matter in this PR somehow. I'm not sure it is easy to work around it in the fuzzer.

We already support Literals with type externref that can be unwrapped to access the underlying any value. This is the same thing in reverse.

Do/should exact casts to externref work on such values?

No, but if they do for now, it might be ok since there are no real engines to compare such executions to.

tlively · 2025-03-14T00:19:59Z

test/lit/passes/string-lowering-instructions.wast

+        (ref.null noextern) ;; The change from stringref to externref does not
+                            ;; cause problems here, nothing needs to change.


Does this unlock any potential code simplifications in StringLowering.cpp?

I wondered this too, but the answer is actually no. While we are doing something much simpler, logically - swapping a type for a supertype, rather than an entirely unrelated type - the actual mechanical change is identical. We just swap all appearances of type X for Y, and don't need to handle any subtyping.

kripken · 2025-03-18T17:44:25Z

We can no longer fuzz strings in v8, as we represent them in a nonstandard way, so I disabled that.

kripken · 2025-03-18T20:44:43Z

I added a readme mention with references to the relevant proposals in the last commit.

kripken · 2025-03-18T21:11:07Z

@tlively I am going to fix this fuzztest error:

https://github.com/WebAssembly/binaryen/actions/runs/13933139917/job/38994921125?pr=7373

but only because luckily it seems obvious what the issue is. In general, how are people intended to debug errors like that?

tlively · 2025-03-19T00:27:02Z

FUZZTEST_PRNG_SEED=(whatever was printed in the failing log) ./bin/binaryen-unittest --gtest_filter=TypeFuzzTest.TestHeapTypeRelationsFuzz should deterministically reproduce the failure.

tlively · 2025-03-19T00:29:55Z

The fact that this shows up in CI at all is a nice property of FuzzTest over our other fuzzer patterns. (Although of course we could run the other fuzzers for limited time on CI as well.)

kripken · 2025-03-19T16:41:43Z

Thanks, now I see it... it was separated from the error itself, for some reason:

FUZZTEST_PRNG_SEED=8gPJDq0F9ObaC0X1WRajSUh_YPiNJkLQ3mvZBc8xll8
[..50 lines of stuff..]
5: Heap type has an invalid supertype
binaryen-unittests: /home/runner/work/binaryen/binaryen/test/gtest/type-domains.cpp:1048: std::vector<HeapType> wasm::(anonymous namespace)::BuildHeapTypes(TypeBuilderPlan): Assertion `built' failed.

=================================================================
=== SETUP FAILURE!

/home/runner/work/binaryen/binaryen/test/gtest/type-builder.cpp:1170: There was a problem with TypeFuzzTest.TestHeapTypeRelationsFuzz.
=================================================================

kripken · 2025-03-19T22:16:38Z

I added commits for fuzztest, and the last commit adds hacks to allow converting string to anyref and back.

kripken · 2025-03-20T16:48:47Z

Fuzzer looks happy now.

kripken added 11 commits March 13, 2025 14:19

yolo

8799f09

changes

5e5b7f5

test

e8208c6

test

69b2d4c

work

7a43386

work

1acdb17

fix

8c98ef3

fi

e9d70b4

fixes

8843f01

test

3029317

work

cb59d41

kripken requested a review from tlively March 13, 2025 23:51

kripken added 2 commits March 13, 2025 17:01

fix fuzzer

2a8328f

more fuzzer fixes

a9d56ab

tlively reviewed Mar 14, 2025

View reviewed changes

kripken added 2 commits March 18, 2025 10:41

improve comment

abb5ac4

we can no longer fuzz strings in v8

9498483

tlively approved these changes Mar 18, 2025

View reviewed changes

kripken added 5 commits March 18, 2025 10:51

disable in CF too

97efb58

format

d45cbe3

another place

2e2e937

update.tets

4c2deb7

readme mention

9f62071

tlively approved these changes Mar 18, 2025

View reviewed changes

kripken added 8 commits March 19, 2025 09:48

fix compiler errors

725fe1c

fix fuzztest

4324c84

fix

a9f7d4d

fix

c0e9e57

oops

b9e0e25

fix

cb9bae4

more

999ca9b

hacks for string=>anyref

b8e172f

Merge remote-tracking branch 'origin/main' into string.is.sub.of.extern

145212c

tlively approved these changes Mar 19, 2025

View reviewed changes

kripken added 2 commits March 19, 2025 16:25

comment

56a887d

fix leaking of contents of anyref literals

1e7b85d

kripken merged commit 087c613 into WebAssembly:main Mar 20, 2025
15 checks passed

kripken deleted the string.is.sub.of.extern branch March 20, 2025 16:49

		(ref.null noextern) ;; The change from stringref to externref does not
		;; cause problems here, nothing needs to change.

[Strings] Make string a subtype of ext, not any #7373

[Strings] Make string a subtype of ext, not any #7373

Uh oh!

Conversation

kripken commented Mar 13, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kripken commented Mar 18, 2025

Uh oh!

kripken commented Mar 18, 2025

Uh oh!

kripken commented Mar 18, 2025

Uh oh!

tlively commented Mar 19, 2025

Uh oh!

tlively commented Mar 19, 2025

Uh oh!

kripken commented Mar 19, 2025

Uh oh!

kripken commented Mar 19, 2025

Uh oh!

kripken commented Mar 20, 2025

Uh oh!

Uh oh!

Uh oh!