fix(es/parser): handle type assertions with non-callable types in binexp#1
Open
steffen-heil-secforge wants to merge 4 commits intomainfrom
Open
fix(es/parser): handle type assertions with non-callable types in binexp#1steffen-heil-secforge wants to merge 4 commits intomainfrom
steffen-heil-secforge wants to merge 4 commits intomainfrom
Conversation
…ary expressions
After type assertions (`as`) and satisfies expressions, the parser needs to
determine whether a following `<` token is a comparison operator or the start
of type parameters. This fix ensures that `<` is lexed as a comparison operator
when the type cannot have type parameters.
Previously only primitive keyword types and literals were handled. This extends
the logic to cover all non-callable type constructs:
- Primitive keyword types (number, string, boolean, etc.)
- Literal types (2, "x", true, 10n)
- this type
- Array types (number[], Array<number>)
- Tuple types ([number, string])
- Union/intersection types (A | B, A & B)
- Type operators (keyof T, readonly T, unique symbol)
- Indexed access types (T[K])
- Conditional types (T extends U ? X : Y)
- Mapped types ({ [K in keyof T]: V })
- Type predicates (x is string)
This prevents parsing errors when these type assertions are followed by
comparison operators.
Examples that now parse correctly:
- (i as number[]) < 5
- (i as [number, string]) < 5
- (i as number | string) < 5
- (i as keyof T) < 5
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
steffen-heil-secforge
changed the title
Only test files were modified to verify the type assertion handling behavior. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
After type assertions (
as) and satisfies expressions, the parser needs to determine whether a following<token is a comparison operator or the start of type parameters. This fix ensures that<is lexed as a comparison operator when the type cannot have type parameters.Description:
Previously only primitive keyword types and literals were handled. This extends the logic to cover all non-callable type constructs:
This prevents parsing errors when these type assertions are followed by comparison operators.
Examples that now parse correctly: