bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node

[Yuan Fu <casouri@gmail.com>]

> On Feb 26, 2023, at 1:41 AM, Mickey Petersen <mickey@masteringemacs.org> wrote:
> 
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
>>> GC has historically never called xmalloc, so the profiler will
>>> likely
>>> crash upon growing the mark stack as well.  I guess another
>>> important
>>> question is why ts_delete_parser is calling xmalloc.
>>> 
>> 
>>> As you see, when we call ts_tree_delete, it calls
>>> ts_subtree_release,
>>> which in turn calls malloc (redirected into our xmalloc).  Is this
>>> expected?  Can you look in the tree-sitter sources and verify that
>>> this is OK?
>> 
>> I had a look, and it seems legit. In tree-sitter, a TSTree (or more
>> precisely, a Subtree) is just some inlined data plus a refcounted
>> pointer to the complete data. This way multiple trees share common
>> subtrees/nodes. Eg, when incrementally parsing, you pass in an old
>> tree and get a new tree, these two trees will share the unchanged part
>> of the tree.
> 
> Would that mean we could possibly preserve node instances -- either the real TS ones, or an Emacs-created facsimile -- between incremental parsing? That would be useful for refactoring.

What kind of exact interface (function) do you want? The treesit-node-outdated error is solely Emacs’s product, tree-sitter itself doesn’t mark a node outdated. It is possible for Emacs to not delete the old tree and give it to you, or allow you to access information of an outdated node.

Yuan