Description
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
Activity
CountBleck commentedon Jun 19, 2024
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 commentedon Jun 19, 2024
Thanks, but I just do this to deal with it (decided on a + sign, makes more sense than -) :
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.
HerrCai0907 commentedon Nov 2, 2024
I don't think it is a bug in AS side. WAT / WASM naming custom section don't have rule to forbidden using this kinds of char.
The reason is that AS use binaryen related stuff but wat2wasm is created by wabt. There are some small difference in those two tools.
But I agree with you that it is a good idea to be compatible with commonly used tools. Maybe we can add a new option and post-process after generating WAT file.
Welcome to create a PR to add a new option to keep compatibility with wabt tools if you want.