`{{in}}` are not interpreted as `'in'` string expressions anymore.
```
<input #in /> // OK
{{in}} // throws
```
fixes#65244
BREAKING CHANGE: `in` variables will throw in template expressions.
Updates the expression parser to handle arrow functions. Since arrow functions share syntax with other AST nodes, we have to detect them by looking ahead and then potentially jumping backwards depending on what we see.
Back in #39323, I added a new `ThisReceiver` node to represent accesses done through `this` and I ended up making it inherit from `ImplicitReceiver`. The logic was that in most cases accessing through `this` was the same as the implicit access.
Over the years this has proven to not be a great idea, because no other AST nodes do this and one has to keep it in mind whenever dealing with `ImplicitReceiver`.
These changes remove the inheritance and update all of the usage sites accordingly.
Fixes two issues that were preventing template literals from being recovered properly if one of the interpolated expressions is broken:
1. We weren't updating the expected brace counter when an interpolation starts which in turn was throwing off the recovery logic in `skip`.
2. When producing tokens for template literals, we were treating the closing brace as an operator whereas other places treat it as a character. Even after fixing the first issue, this was preventing the recovery logic from working correctly.
Fixes#63940.
PR Close#64150
Currently we have a `ParserError` that is used for the expression parser and a `ParseError` that is used everywhere else. These changes consolidate them into the `ParseError` to avoid confusion and make it easier to add more context in the future.
PR Close#62160
Currently our expression parser produces two different expressions for writes: `PropertyWrite` (e.g. `foo.bar = 123`) or `KeyedWrite` (e.g. `foo[0] = 123`). This is inconsistent with other ASTs, like TypeScript's, where writes are represented as binary expressions with a `=` operator and it makes it difficult to implement more write operators like `??=`, because we'd essentially have to duplicate them.
These changes switch the expression parser over to produce binary expressions instead.
PR Close#61682
When the expression parser consumes tokens inside a parenthesized expression, it looks for valid tokens until it hits and invalid one or a closing paren. If it finds an invalid token, it reports and error and tries to recover until it finds a closing paren. The problem is that in such cases, it would produce the `ParenthesizedExpression` and continue parsing **from** from the closing paren which would then produce more errors that add noise to the output and result in an incorrect representation of the user's code. E.g. `foo((event.target as HTMLElement).value)` would be recovered to `foo((event.target)).value` instead of `foo((event.target).value)`.
These changes resolve the issue by skipping over the closing paren at the recovery point.
Fixes#61792.
PR Close#61815
Currently we reuse the same binding parser for all expressions in the template. Under the hood, the parser has a single `errors` array that it passes into all ASTs which means that if there's one binding with an error, those errors will be propagated to all other ASTs in the template.
These changes switch to having a unique `errors` array for each AST so we only report errors once.
Relates to #61792.
PR Close#61793
These helpers are often imported by various tests throughout the
repository, but the helpers aren't exported/exposed from the public
entry-point; even though they confusingly reside in there.
This commit fixes this, and moves the helpers into
`packages/private/testing`. This is a preparation for the `ts_project`
migration where we don't want to leverage deep imports between packages.
PR Close#61472
This commit adds the support for the `in` keyword as a relational operator, with the same precedence as the other relational operators (<,>, <=, >=)
BREAKING CHANGE: 'in' in an expression now refers to the operator
PR Close#58432
Now that the expression AST contains parenthesized expressions, this
refactors the template pipeline to strip out the ones we don't need.
PR Close#60169
Following up on #60127 which added the concept of a parenthesized
expression to the output AST, this does the same for the expression AST.
PR Close#60169
