From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#67977: 30.0.50; tree-sitter: Emacs crashes when accessing treesit-nodes in a narrowed buffer Date: Mon, 01 Jan 2024 23:46:52 -0500 Message-ID: References: <87r0jdddxf.fsf@yandex.ru> <835y0pfkgr.fsf@gnu.org> <1DE32BF7-75D8-4F49-975D-53C782D26016@gmail.com> <08D379EF-1556-4498-8E60-F7972A25752A@gmail.com> <2141703952885@mail.yandex.ru> <10451704018554@mail.yandex.ru> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15750"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Yuan Fu , Eli Zaretskii , Denis Zubarev , "67977@debbugs.gnu.org" <67977@debbugs.gnu.org> To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 02 05:48:14 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 1rKWhI-0003pz-Ny for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 Jan 2024 05:48:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rKWh7-0000PN-5n; Mon, 01 Jan 2024 23:48:01 -0500 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 1rKWh6-0000PD-5b for bug-gnu-emacs@gnu.org; Mon, 01 Jan 2024 23:48:00 -0500 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 1rKWh5-0007Ap-Tc for bug-gnu-emacs@gnu.org; Mon, 01 Jan 2024 23:47:59 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rKWh8-0001e4-2q for bug-gnu-emacs@gnu.org; Mon, 01 Jan 2024 23:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Jan 2024 04:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67977 X-GNU-PR-Package: emacs Original-Received: via spool by 67977-submit@debbugs.gnu.org id=B67977.17041708256168 (code B ref 67977); Tue, 02 Jan 2024 04:48:02 +0000 Original-Received: (at 67977) by debbugs.gnu.org; 2 Jan 2024 04:47:05 +0000 Original-Received: from localhost ([127.0.0.1]:49183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKWgC-0001bP-Iz for submit@debbugs.gnu.org; Mon, 01 Jan 2024 23:47:04 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:17396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKWgA-0001av-N5 for 67977@debbugs.gnu.org; Mon, 01 Jan 2024 23:47:03 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id F1F71441872; Mon, 1 Jan 2024 23:46:54 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704170813; bh=2qt4OSuR01cIhPLaBd0svGTBNrFXEugg6lFkTaVdXHY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=YprNmej6aGX+CMyM12g1eMMBUhXueIFNvbJnRmT+pc4hSVk/vNEE1XvO1UroyV/pZ 2bOKm5AVl0glJll7sdXXci9OAAWBTA02XtqdXPVPrMiuV/3+rdTkgopWUmKEqpxNT6 qwu7Cr7qzy/a4aSxyAfGCPXiJLY/yece9RumYDcRJ65VoaxnuB9jL9pdfAKpqqq625 n05SBBtF8gHmfKBavEZXM4KYRv16NGChRNb4Sk5OP0krJG6r2+2WYRRIMddwl7wD8q j53yJ18ateupVff62dhp4LXj9yqIzdIaRXjOYQyW4B5fyJ1iI+REZiZrgyZMlx6yNj VmgP4qGGvrl+Q== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8F93144185F; Mon, 1 Jan 2024 23:46:53 -0500 (EST) Original-Received: from alfajor (unknown [207.96.224.130]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6BE45121186; Mon, 1 Jan 2024 23:46:53 -0500 (EST) In-Reply-To: (Dmitry Gutov's message of "Sun, 31 Dec 2023 15:40:28 +0200") 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:277215 Archived-At: > diff --git a/lisp/treesit.el b/lisp/treesit.el > index 264b95dc3a3..46ebadcf057 100644 > --- a/lisp/treesit.el > +++ b/lisp/treesit.el > @@ -1150,7 +1150,7 @@ treesit--pre-syntax-ppss > (if (and new-start (< new-start start)) > (progn > (setq treesit--syntax-propertize-start nil) > - (cons new-start end)) > + (cons (max new-start (point-min)) end)) > nil))) > > ;;; Indent Sounds fine to me. Often the caller of `syntax-propertize-function` should widen beforehand, but in cases like `mmm-mode` indeed that's not always desired. > Or maybe syntax-propertize itself should have a protection against going > outside of bounds: > > diff --git a/lisp/emacs-lisp/syntax.el b/lisp/emacs-lisp/syntax.el > index e35992298a6..61a9e79b59c 100644 > --- a/lisp/emacs-lisp/syntax.el > +++ b/lisp/emacs-lisp/syntax.el > @@ -431,7 +431,7 @@ syntax-propertize > (if (or (null new) > (and (>= (car new) start) (<= (cdr new) end))) > nil > - (setq start (car new)) > + (setq start (max (car new) (point-min))) > (setq end (cdr new)) > ;; If there's been a change, we should go through > the > ;; list again since this new position may I think it's preferable for the expand-region function to perform this test. We could `cl-assert` that it's within BOB...EOB to help catch such bugs (and clarify who's in charge of avoiding the problem), but maybe we can mention it in the docstring. But I personally consider that anything that sends buffer positions is in charge to make sure that they're within bounds, unless specifically documented otherwise, so documenting it seems redundant. Stefan