I don't know if this is fixable or should be fixed, but in the following snippet, tree-sitter-c generates a very tall tree, which makes recursively traversing the tree very expensive and overflows the call stack. Querying a tall tree is also way slower.
static hf_register_info hf[] = {
#line 1 "./asn1/rrc/packet-rrc-hfarr.c"
{ &hf_rrc_DL_DCCH_Message_PDU,
{ "DL-DCCH-Message", "rrc.DL_DCCH_Message_element",
FT_NONE, BASE_NONE, NULL, 0,
NULL, HFILL }},
{ &hf_rrc_cellIdentity_c_id,
{"Cell Identifier", "rrc.cellIdentity.c_id",
FT_UINT32, BASE_DEC, NULL, 0,
"The Cell Identifier (C-Id) part of the Cell Identity", HFILL }}
/* ... and tens of thousands of array initializers. */
};
Tree-sitter-c considers the closing brackets in, eg, NULL, HFILL}} errors and skips them, turning a ~10k wide tree into a ~10k tall tree.
I don't know if this is fixable or should be fixed, but in the following snippet, tree-sitter-c generates a very tall tree, which makes recursively traversing the tree very expensive and overflows the call stack. Querying a tall tree is also way slower.
Tree-sitter-c considers the closing brackets in, eg,
NULL, HFILL}}
errors and skips them, turning a ~10k wide tree into a ~10k tall tree.