-
Notifications
You must be signed in to change notification settings - Fork 11
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
Quoted identifiers and invalid lexing #25
Comments
(apologies I hit enter too soon when submitting this, I've now updated the description with the full text intended) |
The error you get depends on the implementation strategy. Either is fine. There is no requirement to report the same errors as the reference interpreter. The reference interpreter does not switch to a different lexer for strings. Instead, well-formed strings are directly specified by a comprehensive regexp that follows the spec literally. Since this one isn't a lexically well-formed string, it does not match that regexp and hence the sequence isn't recognised as a For a production implementation, a more specific error is probably preferable. |
Ok, thanks for confirming, I'll close this as answered. |
I must be missing something, but why does this identifier cause an error? |
Ah, right, the |
In #23 a test was added along the lines of:
This is asserting that a string-based identifier with invalid characters in the string is invalid, but I'm opening this issue to clarify the error emitted here. In the prototype implementation in wasm-tools of #23 the error looks like:
Specifically I'm curious about the lexical format here. Despite both implementations returning an error there's been bits about subtle differences between lexers in the past so I want to smooth this out ideally. I was under the impression that the token was going to be
$"a\tb"
(with the\t
expanded) so during the lexing phase after seeing the$
the adjacent"
means "activate the string parser". In doing so an error is generated. It looks like the spec interpreter ignores the string error and assumes the token ends just before the string, but in wasm-tools I was thinking of reporting the string parsing error.Is there a specific behavior desired here? Is there a downside to reporting the string-parse-error?
The text was updated successfully, but these errors were encountered: