change to a Cargo "workspace" so that a "shared" crate for "plugin-y stuff" can be separated out from the main crate
expose a "Rust-to-Rust FFI" interface for specifying a path to a shared library that exports a "plugin" whose job is to filter potential matches (at the moment an initial tree-sitter query is still required but should probably be optional if you supply a dynamic-library filter (and the filter would just get passed every single tree-sitter AST node)?) (and optionally a string command-line argument to "forward" to the loaded plugin to "configure" it)
To test:
At the moment I included an example plugin in the committed code (though I'd plan on removing it before merging) so you should be able to run cargo build --release --all from the (workspace) root and then run eg ./target/release/tree-sitter-grep -l rust --filter ./target/release/libfilter_after_line_number.dylib --filter-arg 100 ./reference-parameters.scm (the path to the built dynamic library may be different (*.so?) if you aren't on a Mac?) and see a list of reference-type'd function parameters that occur on line numbers after 100
If you (then) run ./target/release/tree-sitter-grep -l rust --filter ./target/release/libfilter_after_line_number.dylib ./reference-parameters.scm you should see an ugly error that it expected you to supply a configuring argument to the filter (via the --filter-arg/-a command-line argument)
If you run ./target/release/tree-sitter-grep -l rust --filter ./target/release/libfilter_after_line_number.dylib -a whee ./reference-parameters.scm you should see an ugly error that the passed filter-argument argument wasn't of the expected parse-able type (ie usize)
You should still be able to invoke without passing a --filter/-f argument
If you're curious about performance, you should be able to observe (eg via the time command?)/it appeared that there was no significant difference in total time (I measured against running queries against the Typescript compiler in Rust codebase) when running with a dynamically-loaded filter vs without
You should be able to create, build + use a different filter (eg one that doesn't accept/require a configuring argument)
helixbass
commented
1 year ago
In this PR:
To test: At the moment I included an example plugin in the committed code (though I'd plan on removing it before merging) so you should be able to run
cargo build --release --allfrom the (workspace) root and then run eg./target/release/tree-sitter-grep -l rust --filter ./target/release/libfilter_after_line_number.dylib --filter-arg 100 ./reference-parameters.scm(the path to the built dynamic library may be different (*.so?) if you aren't on a Mac?) and see a list of reference-type'd function parameters that occur on line numbers after 100If you (then) run
./target/release/tree-sitter-grep -l rust --filter ./target/release/libfilter_after_line_number.dylib ./reference-parameters.scmyou should see an ugly error that it expected you to supply a configuring argument to the filter (via the--filter-arg/-acommand-line argument)If you run
./target/release/tree-sitter-grep -l rust --filter ./target/release/libfilter_after_line_number.dylib -a whee ./reference-parameters.scmyou should see an ugly error that the passed filter-argument argument wasn't of the expected parse-able type (ieusize)You should still be able to invoke without passing a
--filter/-fargumentIf you're curious about performance, you should be able to observe (eg via the
timecommand?)/it appeared that there was no significant difference in total time (I measured against running queries against the Typescript compiler in Rust codebase) when running with a dynamically-loaded filter vs withoutYou should be able to create, build + use a different filter (eg one that doesn't accept/require a configuring argument)