fix: Correct error message for invalid bytes in multiline strings #21459
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change provides a correct error message when an invalid byte is found inside of a multiline string line. Taking the example from #20900:
Before:
After:
I'm not 100% confident in the set of invalid bytes I added in
lowerAstErrors
, as it's just based off of those listed in themultiline_string_literal_line
case ofTokenizer.next()
. I think this part of the PR in particular could benefit from a close second check. :)I initially thought that the similar problem with invalid bytes inside comments (mentioned here), but there isn't a
.comment
variant (only.doc_comment
and.container_doc_comment
) ofToken.Tag
to report the expected token as. Another variant toAst.Error.Tag
could be added to handle this case, but I wanted to check before doing so.One minor nit/ bikeshed question: The rendered error message for this case reads
error: expected 'a string literal', found invalid bytes
. Since this error is triggered by the first single invalid byte encountered by the tokenizer, should this message use "byte" instead?Closes #20900