chore: Switch back to smacker/go-tree-sitter #3069
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Finally remove the dougthor42/go-tree-sitter fork, fixing #2630.
Admittedly we could have done this sooner had I figured things
out sooner... but c'est la vie.
Instead of using the BUILD.bazel files in dougthor42/go-tree-sitter,
we basically vendor the build file via http_archive.
This is different than using patches because non-root Bazel modules
can still make use of the BUILD.bazel files we make.
Background:
The reason we migrated to dougthor42/go-tree-sitter in the first
place was to support python 3.12 grammar. smacker/go-tree-sitter
supported for python 3.12, but made a change to their file structure
that Gazelle was unable to handle. Specifically, the
python/binding.go file indirectly requires a c header file found
in a parent directory, and Gazelle doesn't know how to handle that
for
go_repository
(WORKSPACE) andgo_deps.from_file
(bzlmod).So dougthor42/go-tree-sitter created our own BUILD.bazel files
that included the required filegroups and whatnot, thus negating
the need for Gazelle to generate BUILD.bazel files.
Future Work:
This still doesn't resolve the issues with bumping rules_go and go
seen in #2962, but it does simplify that investigation a bit as
it's just one fewer thing to account for. It also doesn't address
the desire to migrate to the official tree-sitter/go-tree-sitter
repo, but @jbedard found some perf issues with that anyway
(tree-sitter/go-tree-sitter#32).