Pay attention to the parser complexity; this is an issue for this grammar specifically. Look at the generated parser.c, especially the LARGE_STATE_COUNT stat at the top -- this should ideally become smaller, but not larger. It's always helpful to report before/after for these stats. (If the parser is checked into the repo, this is clear from the diff, but here one has to rely on the PR description.)

Good to know, thanks!

If I checked correctly, before and after are the same at LARGE_STATE_COUNT 2271.

@clason @pfoerster I don't know how to do it, but couldn't some CI return and display LARGE_STATE_COUNT (and potentially other stuff) somewhere automatically?

@jdujava @clason I think we have 3 ways to keep track of LARGE_STATE_COUNT:

1. Add something like cat src/parser.c | grep '#define LARGE_STATE_COUNT' | sed 's/#define //g' to the CI job and compare it with main by checking the CI log (probably easy to miss)
2. Same as 1. but report it as a comment under the PR instead (can be quite spammy if you don't add the logic to update the existing comment)
3. Commit parser.c again and check the PR diff (probably the easiest way)

What do you think?

I'd keep it simple (and share your distaste of codecringecov comments). So if option 1 is simple enough to realize (you probably want to test generation anyway?), especially the comparison to main, then I'd recommend that. You can fail the test if the new count is greater than, say 1.2 times the old count or so (free ratchet ;)).

Or just add it to the PR template -- ask people to test tree-sitter g --nobindings and report the state counts; maybe raising awareness is enough?