From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#70438: Emacs error 6 abort when starting rust-ts-mode Date: Fri, 26 Apr 2024 21:32:10 +0300 Message-ID: <86le50x9ed.fsf@gnu.org> References: <868r1cgdk9.fsf@gnu.org> <0439FD61-C3EE-4438-B775-043FE098F41E@gmail.com> <86zfto8jfs.fsf@gnu.org> <86jzkr8gpr.fsf@gnu.org> <6944FFA3-5CEB-4FFA-9A4C-1EFFF8EDC62D@gmail.com> <86cyqi6iyh.fsf@gnu.org> <3FCA9A10-73AD-4B56-B3E7-AB3DF04FD2BF@gmail.com> <86plud1sxk.fsf@gnu.org> <86plucxcot.fsf@gnu.org> <82B0E79F-050A-43B0-BB68-BBD58F37E08E@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40727"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70438@debbugs.gnu.org, sh@bytekomplex.de To: Yuan Fu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 26 20:32:59 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s0QNX-000ALG-9M for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 26 Apr 2024 20:32:59 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s0QNQ-0004LY-7l; Fri, 26 Apr 2024 14:32:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s0QNM-0004L6-Ow for bug-gnu-emacs@gnu.org; Fri, 26 Apr 2024 14:32:48 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s0QNL-00034D-Rb for bug-gnu-emacs@gnu.org; Fri, 26 Apr 2024 14:32:47 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s0QNe-0004LJ-0j for bug-gnu-emacs@gnu.org; Fri, 26 Apr 2024 14:33:06 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 26 Apr 2024 18:33:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70438 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 70438-submit@debbugs.gnu.org id=B70438.171415635916369 (code B ref 70438); Fri, 26 Apr 2024 18:33:05 +0000 Original-Received: (at 70438) by debbugs.gnu.org; 26 Apr 2024 18:32:39 +0000 Original-Received: from localhost ([127.0.0.1]:38427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s0QND-0004Fw-AK for submit@debbugs.gnu.org; Fri, 26 Apr 2024 14:32:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53438) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s0QNB-0004F7-7k for 70438@debbugs.gnu.org; Fri, 26 Apr 2024 14:32:37 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s0QMm-0002yg-Ci; Fri, 26 Apr 2024 14:32:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=rSer/y8EEBGLJ+4eeyf0qW9EH13Wv10mncMbCngS0uc=; b=MV1i5hOanPNkuRwG6wPS IZXVFcR5EH2BmL8BISxMs7NOtYNkpt+MhygKXsz9MJOLzSIf1qeR9kHzrQ2x72tT6Qv3q+M4fjEGT UlJII/t9SBKJ+1E3fccprP8h4c/+bCY1u4goPQxN3E2qV0PmiZwmShEdPIxZu00e+pn+2Vc2jOQ3P Ulj60EFs2hkfWHEvBHXnc68+j9ItvGvuoHnT2wZGxgiRhwF5kTQkLFK0tF7mzsyOdNVwNomyKUKtO LQ9/aYZ0vs6FIEnfOhMlFkA++maQPWg62rV9z4TTKp30Vf/v02u0UhK5sO0wvXbs16qmP/utQprOJ 8GPUiyNjLTzGgQ==; In-Reply-To: <82B0E79F-050A-43B0-BB68-BBD58F37E08E@gmail.com> (message from Yuan Fu on Fri, 26 Apr 2024 10:58:20 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:284008 Archived-At: > From: Yuan Fu > Date: Fri, 26 Apr 2024 10:58:20 -0700 > Cc: sh@bytekomplex.de, > 70438@debbugs.gnu.org > > > We cannot pin a tree-sitter version, because that makes sense only for > > binary distributions. We ship only source tarballs, and for those, > > _any_ tree-sitter version will do -- provided that Emacs is built with > > the same version of tree-sitter with which it will be used, or with > > the version that uses the same ABI. > > > > We could perhaps record the version with which Emacs was built, and > > then reject incompatible versions we find at run time, but since > > tree-sitter doesn't provide any version-related symbols in their > > header files, we cannot do even that. > > > > So the bottom line is still the same: we cannot do anything here, as > > long as the tree-sitter developers think they can break the ABI at > > will. > > Can we statically link tree-sitter? From the look of it, tree-sitter devs don’t plan to not break ABI. We need to do something to prevent Emacs from crashing. Emacs can indeed be statically linked with tree-sitter. But since we, the Emacs project, don't distribute binaries, the decision how to link Emacs with various libraries is made by the distros. And they always prefer shared libraries, because that allows to upgrade the libraries without installing new binaries of dependent programs. > >> This also brings me to the versioning of tree-sitter grammars—they really do change often, we should really consider pinning their version in some way. The current catch-up game we play can’t be scalable. > > > > That's a separate issue: when there's incompatibility with grammar > > libraries, Emacs doesn't crash. > > I can open a separate thread for this. Feel free (although we discussed that in the past already).