Crates.io | npezza93-tree-sitter-swift |
lib.rs | npezza93-tree-sitter-swift |
version | 0.4.4 |
source | src |
created_at | 2024-04-18 14:38:51.116411 |
updated_at | 2024-04-18 14:38:51.116411 |
description | swift grammar for the tree-sitter parsing library |
homepage | |
repository | https://github.com/alex-pinkus/tree-sitter-swift |
max_upload_size | |
id | 1212617 |
size | 34,940,353 |
This contains a tree-sitter
grammar for the Swift programming language.
To use this parser to parse Swift code, you'll want to depend on either the Rust crate or the NPM package.
To use the Rust crate, you'll add this to your Cargo.toml
:
tree-sitter = "0.20.4"
tree-sitter-swift = "=0.4.3"
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 */)?;
To use this from NPM, you'll add similar dependencies to package.json
:
"dependencies: {
"tree-sitter-swift": "0.4.3",
"tree-sitter": "^0.20.0"
}
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);
With this package checked out, a common workflow for editing the grammar will look something like:
grammar.ts
.npm install && npm test
to see whether the change has had impact on existing parsing behavior. The default
npm test
target requires valgrind
to be installed; if you do not have it installed, and do not wish to, you can
substitute tree-sitter test
directly.tree-sitter parse
on some real Swift codebase and see whether (or where) it fails.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.
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
npm install web-tree-sitter tree-sitter-swift
$ npx tree-sitter build-asm ./node_modules/tree-sitter
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);
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:
grammar.json
and parser.c
" action for the appropriate commit.Artifacts
and click on generated-parser-src
. All the relevant parser files will be available in your
download.