bug#70438: Emacs error 6 abort when starting rust-ts-mode

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Sat, 20 Apr 2024 15:20:41 -0700
> Cc: Stefan Heitmann <sh@bytekomplex.de>,
>  70438@debbugs.gnu.org
> 
> 
> 
> > On Apr 20, 2024, at 2:36 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> >> From: Yuan Fu <casouri@gmail.com>
> >> Date: Sat, 20 Apr 2024 01:28:48 -0700
> >> Cc: Stefan Heitmann <sh@bytekomplex.de>,
> >> 70438@debbugs.gnu.org
> >> 
> >>> Yuan, can you please look into this?  It seems the latest versions of
> >>> tree-sitter made some incompatible ABI change (without changing the
> >>> shared-library version, I guess? not nice!), so can we have some
> >>> workaround for this?
> >> 
> >> I think tree-sitter people are working to fix this [1]. I don’t think we 
> >> can do much here, AFAICT tree-site changed ABI without bumping ABI 
> >> version, and Arch and Gentoo are serving old Emacs build this new 
> >> tree-sitter so, which is incompatible and crashed Emacs. We can’t really 
> >> do anything to the Emacs build on people’s machines (though, who knows, 
> >> maybe you CAN cask spells and flip bits).
> >> 
> >> [1] https://github.com/tree-sitter/tree-sitter/issues/3296
> > 
> > It isn't clear to me what would be their solution.  Couldn't we at
> > least reject these new versions at configure time, until they fix the
> > issue?
> 
> From what I understand, rebuilding Emacs with the new header file should fix 
> the issue? Even if we push some change, users need to rebuild Emacs anyway.

I didn't mean to avoid rebuilding Emacs -- that's impossible when
changes are made on the C level.  I meant to make our sources work
with both old and new ABIs.

But maybe I don't have a clear idea of what exactly was the
incompatible change.  Can you describe it here?  Is it the signature
of one or more tree-sitter functions, or is it something else?