Unified: loosen AST schema - #22498
Draft
asgerf wants to merge 11 commits into
Draft
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| final override F::AstNode getAFieldOrChild() { unified_expr_equality_pattern_def(this, result) } | ||
| } | ||
| /** Gets the node corresponding to the field `modifier`. */ | ||
| final F::Modifier getModifier(int i) { unified_expr_pattern_modifier(this, i, result) } |
|
|
||
| /** Gets the node corresponding to the field `type_argument`. */ | ||
| final F::TypeExpr getTypeArgument(int i) { | ||
| final F::Expr getTypeArgument(int i) { |
|
|
||
| /** Gets the node corresponding to the field `modifier`. */ | ||
| final F::Modifier getModifier(int i) { unified_name_pattern_modifier(this, i, result) } | ||
| final F::Modifier getModifier(int i) { unified_named_pattern_modifier(this, i, result) } |
Contributor
Author
|
@copilot investigate the failures in 'unified language tests' fix the underlying problems. (Ignore CI checks about QLdoc) |
unified: Rename back to Identifier
asgerf
force-pushed
the
unified/loosen-schema
branch
from
September 4, 2026 11:17
358fe1a to
99ffe04
Compare
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
2 participants
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.
Refactors the AST to be more loosely typed so that it becomes feasible to translate of various cases of ambiguous syntax into a valid AST. Previously we ended up with invalid ASTs in many cases, often manifesting as "holes" in the AST.
Changes
Expr,Pattern, andTypeExprare merged into a single type, calledExpr. The union types are merged and some of their concrete types likeTupleExprandTuplePatternare merged as well.Identifiersmay now appear in directly in expr/pattern/type context.identifier, giving languages the freedom to classify names where it happens to be easiest. But there isn't a strong need right now, and I see it as a relatively safe refactoring that we can do in the future.Identifierare also renamed to clarify the distinction between two kinds of getters we see in several contexts. We now use the convention:getName()->stringgetNameNode()->Identifier.Ambiguous syntax
As mentioned, the motivation for loosening the AST is to be able to handle ambiguous syntax. For example, in a pattern such as
case Foo.bar(3), we cannot distinguish between these interpretations at translation-time:Foo.barresolves to an enum case with data parameters: this is a constructor pattern, destructuring the incoming value.Foo.barresolves to a static method: this is an expr-equality pattern comparing the incoming value to the return value of the static call.With a more loosely-typed AST, it is mapped to a
CallExprin both cases, and we can recover the distinction by introducing subclasses after the name-binding pass (not done in this PR).See internal issue for more detailed write-up about such cases of ambiguous syntax in Swift.
ExprEqualityPattern
Note that we not longer insert
ExprEqualityPatternat the boundary between expressions and patterns. We previously made a best-effort attempt at this, but produced a malformed AST when we failed to insert it correctly. It might make sense to re-introduce this class and insert it heuristically where we can, but let's wait until we have a more pressing use-case.