Invalid WAT file format

[Mudloop]

Bug description

I'm not sure if this is a bug with AssemblyScript, Binaryen or wat2wasm, but the generated .wat files can contain things like this :

(func $"~lib/map/Map<u32,~lib/string/String>#set:buckets" (param $this i32) (param $buckets i32)
  ..
)

When using wat2wasm, it will complain about "unexpected token ..., expected a numeric index or a name (e.g. 12 or $foo)."

This could be solved by removing the quotes, and using a minus sign instead of the commas. That should still prevent name clashes (since I don't believe a minus sign is a valid character in function or variable names), and that way wat2wam doesn't complain about it.

So in this case, that would make it :

(func $~lib/map/Map<u32-~lib/string/String>#set:buckets (param $this i32) (param $buckets i32)

It's possible that the $"" format is perfectly valid and wat2wasm just doesn't know how to deal with it, but still, probably a good idea to be compatible with commonly used tools?

Steps to reproduce

Build any project which references a generic type with more than 1 generic type parameter, ie Map<u32, string>

AssemblyScript version

0.27.27

[CountBleck]

By the way, Binaryen might be able to convert the WAT back to Wasm, depending on whether the WAT is in the S-expression format or not.

[Mudloop]

By the way, Binaryen might be able to convert the WAT back to Wasm, depending on whether the WAT is in the S-expression format or not.

Thanks, but I just do this to deal with it (decided on a + sign, makes more sense than -) :

function replaceQuotedStrings(input: string): string {
    return input.replace(/\$"([^"]+)"/g, (_, p1) => `$${p1.replace(/,/g, '+')}`);
}

Might be breakable if there's strings that contain this pattern inside of them, but I'll deal with that if that's ever a problem. Not sure if that can even happen, but maybe if a string ends in a $ sign or something. Edit: I guess disallowing whitespace in the pattern might solve that.