Skip to content

Unified: Fix many translation errors when exprs appear in pattern context - #22473

Draft
asgerf wants to merge 37 commits into
github:mainfrom
asgerf:unified/pattern-fixes
Draft

Unified: Fix many translation errors when exprs appear in pattern context#22473
asgerf wants to merge 37 commits into
github:mainfrom
asgerf:unified/pattern-fixes

Conversation

@asgerf

@asgerf asgerf commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

This PR fixes a bunch of issues with the AST mapping, the largest of which has to do with translation of arbitrary expressions that appear in pattern context.

Although the AST from syntax-syntax wraps these in expressionPattern, the expression underneath can contain deeply nested expressions which themselves must be treated as patterns. This means we can't rely on nested pattern-matching and must use context.

A challenge when using context is that many kinds of expressions can appear in pattern context, and the rules for each node kind must handle being in a pattern. After several hopeless attempts I think I found a nice way to express this "coercion" in Yeast (see d95f6c6).

This fixes many type error warnings in practice, but not all of them. I had to stop somewhere. I'll open an internal issue discussing what I know about the remaining cases.

The PR also does a few drive-by fixes:

  • Adds support for string interpolation
  • Maps subscriptCallExpr to unsupportedNode as we're explicitly deferring support for it

Also hide the generated union type from the AST classes
Previously these appeared as nested patterns, meaning they only worked in certain contexts. Decompose the nested patterns into two top-level rules.
This rule matches a labelled function-call, but the general rules for labelled exprs and function calls result in the same AST.
This commits demonstrates the idea we're going to use in later commits, deliberately only done for one expr type so far.
This worked, but it's nice to have a test for it
@asgerf asgerf added the no-change-note-required This PR does not need a change note label Sep 1, 2026
final F::Expr getAnElement() { result = this.getElement(_) }

/** Gets the node corresponding to the field `modifier`. */
final F::Modifier getModifier(int i) {
This is a result of mapping subscriptCallExpr -> unsupportedNode
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

no-change-note-required This PR does not need a change note

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants