chore: Bump Rust version(s)

[alexpovel]

Upstream base tree-sitter has seen some updates this now
incorporates.

It also bumps this crate's version. The scheme chosen is for the
Rust crate's version to be in lockstep with the tree-sitter
dependency. Looking at the major tree-sitter libraries,
this seems to be the general style chosen. For example:

• Python: https://github.com/tree-sitter/tree-sitter-python/blob/0dee05ef958ba2eae88d1e65f24b33cad70d4367/Cargo.toml
• TypeScript: https://github.com/tree-sitter/tree-sitter-typescript/blob/198d03553f43a45b92ac5d0ee167db3fec6a6fd6/Cargo.toml

The commit also adjust the Rust code to be
compatible (the &'static change was just a lint,
not a compile error). cargo build and cargo test now pass.

[MichaHoffmann]

Lgtm @amaanq can you ptal?

[clason]

We don't tie parser versions to the tree-sitter crate (that's what ABI is for, which can be checked independently of the version).

And aren't the bindings autogenerated?

[alexpovel]

Thanks for your comments!

I'm not sure I understand the versioning scheme. Would appreciate guidance here!

---

Starting from current HEAD at 9e3ec98 , just bumping tree-sitter as:

diff --git a/Cargo.toml b/Cargo.toml
index d0b9dc6..6341487 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -15,7 +15,7 @@ include = ["bindings/rust/*", "grammar.js", "queries/*", "src/*"]
 path = "bindings/rust/lib.rs"
 
 [dependencies]
-tree-sitter = "~0.20.10"
+tree-sitter = ">=0.22.0"
 
 [build-dependencies]
 cc = "1.0"

I can regenerate bindings as

cargo install [email protected] && ~/.cargo/bin/tree-sitter generate

using 0.22.6 as you did the other day in 9bb9943 . Now git diff bindings/rust gives

diff --git a/bindings/rust/build.rs b/bindings/rust/build.rs
index 8851fed..718f897 100644
--- a/bindings/rust/build.rs
+++ b/bindings/rust/build.rs
@@ -7,6 +7,9 @@ fn main() {
         .flag_if_supported("-Wno-unused-parameter")
         .flag_if_supported("-Wno-unused-but-set-variable")
         .flag_if_supported("-Wno-trigraphs");
+    #[cfg(target_env = "msvc")]
+    c_config.flag("-utf-8");
+
     let parser_path = src_dir.join("parser.c");
     c_config.file(&parser_path);

aka no changes in lib.rs. cargo test then fails. The changes necessary for Rust to compile I added manually. I will amend the above diff from generate to the PR as well.

---

Re: versioning scheme. I found this example where the tree-sitter dependency was bumped a minor, while the Crate version wasn't.

Is the versioning I chose here wrong? I'm happy to adjust!

[clason]

The versioning scheme is basically semver, from the point of view of queries (so reflecting minor/major/breaking changes in the grammar only).

And try removing the bindings first; some files are not touched if they already exist.

[alexpovel]

Thank you. I regenerated after removing first, which gives slightly different results. Didn't squash yet to keep it readable.

Re: semver. The context for my PR is just that I'm trying to get this crate onto crates.io (with tree-sitter dep as >=0.22.0). It's not been released on there yet. So an initial release as 0.0.1 (the current one) would probably be fine with semver and is totally fine with my use case. Which initial version do you prefer?

[clason]

Actually, versioning and publishing should be handled by our workflows; we'd prefer it if there was no "rogue publishing" that can interfere with that.

@ObserverOfTime

[ObserverOfTime]

Publishing should be handled by our workflows.
Versioning should start at 0.1.0 or 1.0.0 (0.0.1 = experimental = unpublishable).
(Actually 1.2.0 or 2.0.0 since the parser is currently at 1.1.0.)

P.S. The CLI will help with versioning in the future.

[MichaHoffmann]

Do we have the secrets configured for this repository? I would add the actions then today

[clason]

Ideally they should be available org-wide, like the NPM token (as we eventually want to publish ALL THE PARSERS).

[ObserverOfTime]

Unfortunately, crates does not support team tokens and pypi has yet to approve the org.
Also, for the org-wide npm token to work, the package name must be @tree-sitter-grammars/tree-sitter-hcl.

[clason]

@ObserverOfTime Can you set up the token and the publish workflow for this repo then?

[ObserverOfTime]

Sure, but it would be published on my account.

[clason]

Can we use our github app? It's a bit annoying that we have to tie packages to personal accounts that may move on, orphaning the package.

[ObserverOfTime]

The app is for GitHub tokens, not registry tokens.

[alexpovel]

For reference: https://doc.rust-lang.org/cargo/reference/publishing.html#cargo-owner . Multiple individuals (all fully entitled) can be made owners, alleviating the issue of orphaning. Teams can then be entitled to publish crate updates etc.

[alexpovel]

Hey folks, is there a way I can help move this forward?