* fix(deps): upgrade native tree-sitter to 0.25.1 * fix(tree-sitter): preserve sync loading and update verified capture baselines Route C# scope queries through the synchronous native grammar loader so the compiled analyze module remains require-compatible on Node 22.18. Refresh only the audited empty-Python-module and renamed-PHP-fixture captures, and pin the runtime assertion to 0.25.1. Validated 479 targeted tests, all 16 scope-capture benchmark cases, Python capture/import guards, compiled C# worker parsing, build, typecheck and formatting. Performance budgets are unchanged. * fix(tree-sitter): refresh upstream vendors and preserve parser semantics * fix(ci): refresh prebuilds and support Windows ARM Refresh macOS, Linux ARM, and Windows x64 grammar binaries from the successful native CI builds. Pin node-gyp 12.4.0 so the Windows ARM jobs recognize Visual Studio 2026. Use local Git filtering for E2E to avoid PR-files API timeouts on generated parser diffs. Validation: 143 focused tests, Actionlint, and all 16 scope-capture benchmark checks passed. Full npm test run started; native database suites still running. * fix(ci): refresh Windows ARM grammar prebuilds Import all seven Windows ARM grammar artifacts from successful native build run 37965761760. Artifact filenames and SHA-256 hashes verified; all 42 native build jobs passed. Validation: 31 prebuild coverage tests passed. * fix(bench): stabilize scope capture timing guard Warm each input size seven times and use 21 median samples while retaining isolated timing blocks. Yield between languages so native finalizers release allocations outside the measured sections. Keep all fixture sizes, fingerprints, scaling formulas, and budgets unchanged. Validation: all 16 language guards passed with a 2 GB heap limit (1.38 deep-chain ratio; 1518 MB peak RSS). Linear and quadratic controls passed their expected guard outcomes. Formatting and graph change analysis passed. Full npm test is running without failures so far. * fix(parser): reduce TypeScript capture traversal cost * fix(test): await parser worker readiness before teardown * fix(parser): load C# synchronously in workers * fix(grpc): resolve native proto detections against their own file With the native proto grammar active, sibling .proto files that declare the same short service name under different packages tied in the directory-based resolveProtoConflict heuristic and both providers were dropped. A proto-origin detection already knows its defining file, so use that file's entry before falling back to the heuristic. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * ci(packaging): assert native grammars load from the installed tarball The packaged-install smoke only ran `gitnexus --version`, so a grammar that failed to load from the published package (bundled runtime, patched peer manifests, vendored prebuilds, C# sync loader, Protobuf wrapper) would ship silently; the dev-tree ABI smoke also accepts vendored grammars that report unavailable. Parse a sample for every registered grammar plus the native Protobuf plugin from the installed package, on the main thread and in a worker thread. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * ci(tree-sitter): track compatibility workarounds instead of 0.25 readiness The daily readiness report still targeted tree-sitter@0.25.0, so after the upgrade it would keep reporting "Blocked" and never close its tracking issue. Repurpose it to track what we carry for the bundled runtime: derive the target from the package.json pin, list each pack-time peer patch from prepare-tree-sitter-bundle.cjs with its drop condition (bump, wait for an upstream release, transitive, or intentionally pinned), and reword the buckets. The workflow adopts the issue opened under the old title. Also update the grammar-update-monitor header and auto-PR text, which still described the 0.21.1 runtime and a tree-sitter-c hold. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(dart): assert both nested labels target the loop; fix Zig call-shape doc The nested-label CFG test only jumped to `outer` and checked reachability, which still passes when a jump is retargeted to the inner loop (its exit reaches the outer header). Jump to both labels and assert the exact `continue` edges; dropping the inner label now fails the test. Update the Zig callable-flow comment: call_expression now wraps actuals in a required `arguments:` field. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Codex <codex@openai.com> Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com> Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| bindings/node | ||
| prebuilds | ||
| src | ||
| binding.gyp | ||
| LICENSE | ||
| package.json | ||
| README.md | ||
GitNexus vendor notice
This runtime package uses upstream sources at 7b7909f2f6b9414be0958275f4c8e5d69c3bca43
with Tree-sitter 0.25.1. The copied C sources, scanner (where present),
headers, node metadata and native binding source are upstream-identical.
GitNexus preserves its synchronous CommonJS loader and hardened binding.gyp.
The exact version and source commit are recorded in package.json.
All six platform/architecture prebuilds are built from this vendored source by
.github/workflows/build-tree-sitter-prebuilds.yml. Load through
requireVendoredGrammar; do not copy the package into node_modules.
See the vendor update policy, including the Swift release hold.
Do not edit generated C files by hand.
tree-sitter-swift
This contains a tree-sitter grammar for the Swift programming language.
Getting started
To use this parser to parse Swift code, you'll want to depend on either the Rust crate or the NPM package.
Rust
To use the Rust crate, you'll add this to your Cargo.toml:
tree-sitter = "0.23.0"
tree-sitter-swift = "=0.7.0"
Then you can use a tree-sitter parser with the language declared here:
let mut parser = tree_sitter::Parser::new();
parser.set_language(tree_sitter_swift::language())?;
// ...
let tree = parser.parse(&my_source_code, None)
.ok_or_else(|| /* error handling code */)?;
Javascript
To use this from NPM, you'll add similar dependencies to package.json:
"dependencies: {
"tree-sitter-swift": "0.7.0",
"tree-sitter": "^0.22.1"
}
Your usage of the parser will look like:
const Parser = require("tree-sitter");
const Swift = require("tree-sitter-swift");
const parser = new Parser();
parser.setLanguage(Swift);
// ...
const tree = parser.parse(mySourceCode);
Editing the grammar
With this package checked out, a common workflow for editing the grammar will look something like:
- Make a change to
grammar.ts. - Run
npm install && npm testto see whether the change has had impact on existing parsing behavior. The defaultnpm testtarget requiresvalgrindto be installed; if you do not have it installed, and do not wish to, you can substitutetree-sitter testdirectly. - Run
tree-sitter parseon some real Swift codebase and see whether (or where) it fails. - Use any failures to create new corpus test cases.
Contributions
All contributions to this repository are welcome.
If said contribution is to check generated files (e.g., parser.c) into the repository, be aware that your contribution will not be accepted. Make sure to read the FAQ entry and the prior discussions and compromises that have occurred already on this topic.
Using tree-sitter-swift in Web Assembly
To use tree-sitter-swift as a language for the web bindings version tree-sitter, which will likely be a more modern version than the published node module. see. Follow the instructions below
- Install the node modules
npm install web-tree-sitter tree-sitter-swift - Run the tree-sitter cli to create the wasm bundle
$ npx tree-sitter build-asm ./node_modules/tree-sitter - Boot tree-sitter wasm like this.
const Parser = require('web-tree-sitter');
async function run() {
//needs to happen first
await Parser.init();
//wait for the load of swift
const Swift = await Parser.Language.load('./tree-sitter-swift.wasm');
const parser = new Parser();
parser.setLanguage(Swift);
//Parse your swift code here.
const tree = parser.parse('print("Hello, World!")');
}
//if you want to run this
run().then(console.log, console.error);
Frequently asked questions
Where is your parser.c?
This repository currently omits most of the code that is autogenerated during a build. This means, for instance, that
grammar.json and parser.c are both only available following a build. It also significantly reduces noise during
diffs.
The side benefit of not checking in parser.c is that you can guarantee backwards compatibility. Parsers generated by
the tree-sitter CLI aren't always backwards compatible. If you need a parser, generate it yourself using the CLI; all
the information to do so is available in this package. By doing that, you'll also know for sure that your parser version
and your library version are compatible.
If you need a parser.c, and you don't care about the tree-sitter version, but you don't have a local setup that would
allow you to obtain the parser, you can just download one from a recent workflow run in this package. To do so:
- Go to the GitHub actions page for this repository.
- Click on the "Publish
grammar.jsonandparser.c" action for the appropriate commit. - Go down to
Artifactsand click ongenerated-parser-src. All the relevant parser files will be available in your download.