You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
statichf_register_infohf[] = {
#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.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: