Skip to content

Unified: Fix a bunch of extractor failures - #22683

Open
tausbn wants to merge 7 commits into
mainfrom
tausbn/unified-fix-a-bunch-of-extractor-failures
Open

tausbn wants to merge 7 commits into
mainfrom
tausbn/unified-fix-a-bunch-of-extractor-failures

Conversation

@tausbn

@tausbn tausbn commented Sep 25, 2026

Copy link
Copy Markdown
Contributor

Addresses all of the extraction failures I encountered on swiftlang/swift. Every other failure comes from files that are actually malformed in some way (and thus rejected by the official compiler).

The culprit in this case was the legacy syntax

```
infix operator *** { associativity left precedence 140 }
```

which is not accepted by the current Swift parser. Because of this, the
offending tokens were placed inside the emitted AST as an unexpected
collection of syntax nodes. This then got serialised into an array
inside of an array in the JSON produced. The deserialiser did not expect
arrays to nest in this way, which caused the deserialisation failure
(which then in turn brought down the entire extractor).

To fix this, we now recursively flatten such arrays, rather than just
the top level.
Previously, if desugaring failed, then it would panic and take down the
whole extractor. Now it just writes an error message to the output (and
continues with the rest of the files).
Some files in `swiftlang/swift` ran into this limit which caused
desugaring to fail. The current bump should give us ample headroom.
We were running into this on valid files from `swiftlang/swift`
(admittedly ones explicitly testing the limits of the Swift compiler).
Unfortunately, there's no way to just bump the limit -- it's 128 or
infinity.
These are apparently valid in Swift (there's a test for it in
`swiftlang/swift` that is parsed -- with a warning -- by the Swift
compiler).

To allow these, the SwiftSyntaxFFI now passes a string-with-length
rather than a NUL-terminated string.
@tausbn tausbn added the no-change-note-required This PR does not need a change note label Sep 25, 2026
@tausbn
tausbn marked this pull request as ready for review September 25, 2026 13:42
Copilot AI balanced review requested due to automatic review settings September 25, 2026 13:42
@tausbn
tausbn requested review from a team as code owners September 25, 2026 13:42

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot review overview

🟡 Changes recommended

Unbounded recursive JSON handling can terminate the extractor through stack overflow.

Get a fresh assessment by requesting another Copilot review.

Review effort: Balanced
Findings: 1 High severity

Open (1)
What changed in this PR

Improves Unified Swift extraction resilience for problematic source files and deeply nested syntax.

Changes:

  • Supports interior NUL bytes and nested Swift syntax.
  • Continues extraction after per-file failures.
  • Raises desugaring depth limits.
File Description
SwiftSyntaxFFI.swift Accepts length-delimited UTF-8 buffers.
swift-syntax-rs/​src/​lib.rs Updates the Rust FFI wrapper.
adapter.rs Handles nested collections and deep JSON.
unified/​extractor/​Cargo.toml Enables unbounded JSON depth.
shared/​yeast/​src/​lib.rs Raises rewrite-depth limit.
simple.rs Adopts fallible extraction API.
extractor/​mod.rs Returns parsing and desugaring errors.
driver.rs Isolates failures to individual files.
desugaring.rs Propagates extraction errors.
Cargo.lock Records the direct Serde dependency.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread unified/extractor/src/languages/swift/adapter.rs
To avoid malicious JSON from taking down the extractor, we calculate the
nesting depth before attempting the deserialisation. A limit of 2048
seems like it should cover our needs for the time being.
@tausbn
tausbn requested a review from a team as a code owner September 25, 2026 14:35

This branch has not been deployed

No deployments
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