Repository navigation
fix(compiler): do not allow unterminated interpolation to leak into later tokens - #42605
petebacondarwin wants to merge 2 commits into
Conversation
98c21fa to
4cee71b
Compare
|
@AndrewKushnir can you check this new code against the failing targets in G3? Thanks! |
|
@petebacondarwin FYI, presubmits (including TGP) are now "green" 🎉 |
…ater tokens
When consuming a text token, the lexer tracks whether it is reading characters
from inside an interpolation so that it can identify invalid ICU expressions.
Inside an interpolation there will be no ICU expression so it is safe to
have unmatched `{` characters, but outside an interpolation this is an error.
Previously, if an interpolation was started, by an opening marker (e.g. `{{`)
in a text token but the text came to an end before the closing marker (e.g. `}}`)
then the lexer was not clearing its internal state that tracked that it was
inside an interpolation. When the next text token was being consumed,
the lexer, incorrectly thought it was already within an interpolation.
This resulted in invalid ICU expression errors not being reported.
For example, in the following snippet, the first text block has a prematurely
ended interpolation, and the second text block contains an invalid `{` character.
```
<div>{{</div>
<div>{</div>
```
Previously, the lexer would not have identified this as an error. Now there
will be an EOF error that looks like:
```
TS-995002: Unexpected character "EOF"
(Do you have an unescaped "{" in your template? Use "{{ '{' }}") to escape it.)
```
Previously the lexer would break out of consuming a text token if it contains a `<` character. Then if the next characters did not indicate an HTML syntax item, such as a tag or comment, then it would start a new text token. These consecutive text tokens are then merged into each other in a post tokenization step. In the commit before this, interpolation no longer leaks across text tokens. The approach given above to handling `<` characters that appear in text is no longer adequate. This change ensures that the lexer only breaks out of a text token if the next characters indicate a valid HTML tag, comment, CDATA etc.
4cee71b to
1ad8070
Compare
|
Caretaker: since the last presubmit, I have only changed the wording of the commit messages, so there should be no need to re-run the presubmit, unless you want to check for backsliding. |
|
@petebacondarwin Sounds good, is that the only reason you have |
|
@dylhunn I've forced g3 status and removed the |
…#42605) Previously the lexer would break out of consuming a text token if it contains a `<` character. Then if the next characters did not indicate an HTML syntax item, such as a tag or comment, then it would start a new text token. These consecutive text tokens are then merged into each other in a post tokenization step. In the commit before this, interpolation no longer leaks across text tokens. The approach given above to handling `<` characters that appear in text is no longer adequate. This change ensures that the lexer only breaks out of a text token if the next characters indicate a valid HTML tag, comment, CDATA etc. PR Close #42605
…ater tokens (#42605) When consuming a text token, the lexer tracks whether it is reading characters from inside an interpolation so that it can identify invalid ICU expressions. Inside an interpolation there will be no ICU expression so it is safe to have unmatched `{` characters, but outside an interpolation this is an error. Previously, if an interpolation was started, by an opening marker (e.g. `{{`) in a text token but the text came to an end before the closing marker (e.g. `}}`) then the lexer was not clearing its internal state that tracked that it was inside an interpolation. When the next text token was being consumed, the lexer, incorrectly thought it was already within an interpolation. This resulted in invalid ICU expression errors not being reported. For example, in the following snippet, the first text block has a prematurely ended interpolation, and the second text block contains an invalid `{` character. ``` <div>{{</div> <div>{</div> ``` Previously, the lexer would not have identified this as an error. Now there will be an EOF error that looks like: ``` TS-995002: Unexpected character "EOF" (Do you have an unescaped "{" in your template? Use "{{ '{' }}") to escape it.) ``` PR Close #42605
…#42605) Previously the lexer would break out of consuming a text token if it contains a `<` character. Then if the next characters did not indicate an HTML syntax item, such as a tag or comment, then it would start a new text token. These consecutive text tokens are then merged into each other in a post tokenization step. In the commit before this, interpolation no longer leaks across text tokens. The approach given above to handling `<` characters that appear in text is no longer adequate. This change ensures that the lexer only breaks out of a text token if the next characters indicate a valid HTML tag, comment, CDATA etc. PR Close #42605
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
The lexer tracks whether it is reading characters from inside an interpolation
when consuming a text token, so that it can identify invalid ICU expressions.
Inside an interpolation there will be no ICU expression so it is safe to
have unmatched
{characters, but outside this is an error.Previously, if an interpolation was started, by an opening marker (e.g.
{{)in the text, but the text came to an end before the closing marker (e.g.
}})then the lexer was not clearing its internal state that tracked that it was
inside an interpolation. So if when a new text token was being consumed,
the lexer, incorrectly thought it was already within an interpolation.
This resulted in invalid ICU expression errors not being reported.
There are instances of this error being hidden inside G3, and so these will
need to be fixed in order to land this change.