-
-
Notifications
You must be signed in to change notification settings - Fork 667
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Invalid WAT file format #2854
Comments
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 -) :
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. |
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. 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. |
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 :
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 :
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
The text was updated successfully, but these errors were encountered: