feat: Add support for starlark. #509

amartani · 2025-07-19T08:38:49+02:00

amartani commented

2025-07-19 08:38:49 +02:00

Add support for starlark (bazel's config language).

Add support for starlark ([bazel](https://bazel.build/)'s config language).

amartani added 1 commit

2025-07-19 08:38:50 +02:00

feat: Add support for starlark.

/ test (pull_request) Successful in 1m34s

Details

b0697d08d3

ada4a requested changes

2025-07-21 19:33:35 +02:00

ada4a left a comment

Welcome, and thanks for the PR! The LangProfile looks thought out, and it's nice that you have multiple tests. After a bit of tweaking of simple_merge and an additional signature for list elements, I think this should be good to go!

Welcome, and thanks for the PR! The `LangProfile` looks thought out, and it's nice that you have multiple tests. After a bit of tweaking of `simple_merge` and an additional signature for list elements, I think this should be good to go!

examples/starlark/working/simple_merge/Expected.bzl Outdated

					
				@ -0,0 +1,12 @@

				load("@rules_rust//rust:defs.bzl", "rust_library")

ada4a commented

2025-07-21 19:14:10 +02:00

I think this conflict could've been resolved even with a default line-based merge algorithm, since the loads are only changed by the right side, and the deps only by the left side. To actually check that the commutativity works, one would need to try adding something from both sides. See cdb57b0744/examples/rust/working/use_statements for an example

I think this conflict could've been resolved even with a default line-based merge algorithm, since the `load`s are only changed by the right side, and the `deps` only by the left side. To actually check that the commutativity works, one would need to try adding something from _both_ sides. See https://codeberg.org/mergiraf/mergiraf/src/commit/cdb57b0744476e4248da70a26e427a55ada7ffe4/examples/rust/working/use_statements for an example

amartani commented

2025-07-28 03:34:34 +02:00

I added a new load_statement test case for that, thanks!

I added a new `load_statement` test case for that, thanks!

❤️ 1

ada4a marked this conversation as resolved

examples/starlark/working/simple_merge/Right.bzl Outdated

					
				@ -0,0 +5,4 @@

				    name = "lib",

				    srcs = ["src/lib.rs"],

				    deps = [

				        "@crates//:log",

ada4a commented

2025-07-21 19:27:57 +02:00

One thing you'll probably want is to define a signature for the elements of a list, so that duplicates can be detected. Judging by the examples, it looks like they are all strings, which is a bit unfortunate but not that big of a problem I think. The list gets parsed as follows:

value: list
 ├[
 ├string
 │ ├string_start "
 │ ├string_content @crates//:log
 │ └string_end "
 ├,
 ├string
 │ ├string_start "
 │ ├string_content @crates//:serde
 │ └string_end "
 ├,
 └]

so I think the signature will need to be defined on string, and get its value from string_content (I don't think string_{start,end} can be meaningfully different, maybe become single-quotes at most)

One thing you'll probably want is to define a signature for the elements of a list, so that duplicates can be detected. Judging by the examples, it looks like they are all strings, which is a bit unfortunate but not that big of a problem I think. The list gets parsed as follows: ``` value: list ├[ ├string │ ├string_start " │ ├string_content @crates//:log │ └string_end " ├, ├string │ ├string_start " │ ├string_content @crates//:serde │ └string_end " ├, └] ``` so I think the signature will need to be defined on `string`, and get its value from `string_content` (I don't think `string_{start,end}` can be meaningfully different, maybe become single-quotes at most)

amartani commented

2025-07-28 03:36:33 +02:00

Not every list in starlark can be deduplicated, and they may not even be commutative... I added commutative rules for some of the cases where they are in a new commutative_lists test case; see if that makes sense.

Not every list in starlark can be deduplicated, and they may not even be commutative... I added commutative rules for some of the cases where they are in a new `commutative_lists` test case; see if that makes sense.

amartani added 5 commits

2025-07-28 03:30:35 +02:00

Add commutative parents for expression statement at module level and for adfa3e3922

lists.

Only consider specific lists as commutative. 523ed00502

Simplify using any-of 24bac10880

Merge remote-tracking branch 'origin/main' into martani/add-starlark 7f4cd3913c

Add flattened_nodes

/ test (pull_request) Successful in 1m24s

Details

e6aee04cf1

amartani added 1 commit

2025-07-28 03:33:24 +02:00

Rename simple_merge -> commutative_lists

/ test (pull_request) Successful in 33s

Details

ea1a2f8546

amartani commented

2025-07-28 03:37:10 +02:00

Thanks for the review! PTAL

requested review from ada4a

2025-07-28 03:37:12 +02:00

amartani reviewed

2025-07-28 03:41:27 +02:00

examples/starlark/working/load_statements/Expected.bzl

					
				@ -0,0 +12,4 @@

				    name = "python_lib",

				    srcs = ["python_lib.py"],

				)

				rust_library(

amartani commented

2025-07-28 03:41:27 +02:00

Question: Ideally, this merge would preserve a blank newline between each of the calls. I tried to do that by changing the CommutativeParent separator to be "\n\n", but that then causes a newline to be added between load() calls above as well, and since they are all expression_statement in the starlark tree-sitter library, it's not so easy to differentiate between them. Any suggestions on it? I think this is not a big deal, but it does mean that users will likely need to run a formatter after the merge resolution.

Question: Ideally, this merge would preserve a blank newline between each of the calls. I tried to do that by changing the CommutativeParent separator to be `"\n\n"`, but that then causes a newline to be added between `load()` calls above as well, and since they are all `expression_statement` in the starlark tree-sitter library, it's not so easy to differentiate between them. Any suggestions on it? I think this is not a big deal, but it does mean that users will likely need to run a formatter after the merge resolution.

wetneb commented

2025-07-28 06:00:01 +02:00

This sounds like something that could be fixed by #373. Alternatively, as you say, the grammar could be changed to expose different node types at this level, which would make it possible to define children groups with different default separators.

This sounds like something that could be fixed by https://codeberg.org/mergiraf/mergiraf/issues/373. Alternatively, as you say, the grammar could be changed to expose different node types at this level, which would make it possible to define children groups with different default separators.

wetneb approved these changes

2025-07-28 23:51:34 +02:00

wetneb left a comment

Good to go as far as I am concerned. Thanks for the PR! :)

wetneb reviewed

2025-08-01 18:15:33 +02:00

src/supported_langs.rs

					
				@ -1102,0 +1129,4 @@

				                CommutativeParent::from_query(

				                    r#"(call

				                         function: (identifier) @func_name (#any-of? @func_name "exports_files" "glob")

				                         arguments: (argument_list (list) @commutative))"#,