bug#59426: 29.0.50; [tree-sitter] Some functions exceed maximum recursion limit

[Yuan Fu]

> On Nov 24, 2022, at 2:24 AM, Mattias Engdegård <mattiase@acm.org> wrote:
> 
> 24 nov. 2022 kl. 10.17 skrev Yuan Fu <casouri@gmail.com>:
> 
>> Does it worth the complexity tho? We only need a stack if we want to support 
>> this scenario, in which case tree-sitter has a wrong parse tree. Instead of 
>> spending the time and resource to go down that deep tree, it’s better to 
>> fail early, and let the user decide to either give up on weird files, or try 
>> some other approximation.
>> 
>> It’s too early to tell if being able to go down arbitrarily deep into a deep 
>> tree is useful. The only use of traversing the whole tree right now is to 
>> generate the imenu indexes, which don’t really need to go down more than 10 
>> levels, since most defun nodes we are interested in are either top-level or 
>> near top-level.
> 
> You may very well be right about that.

That brings us back to the original question: what limit should we use? I 
suggest we use a smaller number since normal tree should never be very tall. 
Running the following code tells me the height of the tree for xdisp.c is 30:

(defun measure-height (node)
  (let ((children (treesit-node-children node t)))
    (if children
        (1+ (apply #'max (mapcar #'measure-height children)))
      1)))
;; In xdisp.c:
(measure-height (treesit-buffer-root-node))

Maybe a limit in the range of hundreds or thousands? 800?

> 
>> So I’d prefer we keep it simple and have a hard limit for now. If we later 
>> find that a stack is favorable we can always add it in.
> 
> That sounds good. Maybe the #line snag in the packet-rrc.c example should be 
> reported upstream?

I stole your sample and opened an issue on their GitHub repo: 

https://github.com/tree-sitter/tree-sitter-c/issues/118

Yuan