Skip to content
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

Updating top repository version #353

Merged
merged 5 commits into from
Feb 13, 2024
Merged

Updating top repository version #353

merged 5 commits into from
Feb 13, 2024

Conversation

github-actions[bot]
Copy link

No description provided.

@alex-pinkus alex-pinkus force-pushed the repo-update-2024-02-11 branch from e30a7d7 to 76c1953 Compare February 13, 2024 05:38
@alex-pinkus alex-pinkus merged commit dabbcf9 into main Feb 13, 2024
55 checks passed
@alex-pinkus alex-pinkus deleted the repo-update-2024-02-11 branch February 13, 2024 05:43
alex-pinkus added a commit that referenced this pull request Mar 3, 2024
In #353, adding `_parenthesized_type` caused new parse failures where
the parser now resolved away from `tuple_type` too early. Specifically,
when parsing an expression like `[(any Foo) ...`, the `tuple_type`
interpretation must still be valid at that point in the expression in
case we're about to see a `?`.

The truly robust thing to do would be to support `$.tuple_type` as the
target of the navigation expression. However, this leads to a large
number of additional parse failures, as seen in #360. To avoid all of
that, we add support in the opposite direction: allow `tuple_type` to be
resolved using `_parenthesized_type`, so that the parser seeing the
latter does not cause it to invalidate the former.
alex-pinkus added a commit that referenced this pull request Mar 3, 2024
In #353, adding `_parenthesized_type` caused new parse failures where
the parser now resolved away from `tuple_type` too early. Specifically,
when parsing an expression like `[(any Foo) ...`, the `tuple_type`
interpretation must still be valid at that point in the expression in
case we're about to see a `?`.

The truly robust thing to do would be to support `$.tuple_type` as the
target of the navigation expression. However, this leads to a large
number of additional parse failures, as seen in #360. To avoid all of
that, we add support in the opposite direction: allow `tuple_type` to be
resolved using `_parenthesized_type`, so that the parser seeing the
latter does not cause it to invalidate the former.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant