From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#64133: CC Mode 5.35.2 (C/*l); incorrect indentation for an arrays of structs. Date: Wed, 21 Jun 2023 10:39:39 +0000 Message-ID: References: <831qiaqfxh.fsf@gnu.org> <83y1kioxzv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3054"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 64133@debbugs.gnu.org To: Jeff Norden Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 21 12:41:04 2023 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 1qBvGn-0000de-Ub for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 21 Jun 2023 12:41:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qBvFu-0000qt-2t; Wed, 21 Jun 2023 06:40:06 -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 1qBvFr-0000pV-Ge for bug-gnu-emacs@gnu.org; Wed, 21 Jun 2023 06:40:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qBvFr-0001oy-3q for bug-gnu-emacs@gnu.org; Wed, 21 Jun 2023 06:40:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qBvFq-0008Vc-Gv for bug-gnu-emacs@gnu.org; Wed, 21 Jun 2023 06:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 Jun 2023 10:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64133 X-GNU-PR-Package: emacs Original-Received: via spool by 64133-submit@debbugs.gnu.org id=B64133.168734398732679 (code B ref 64133); Wed, 21 Jun 2023 10:40:02 +0000 Original-Received: (at 64133) by debbugs.gnu.org; 21 Jun 2023 10:39:47 +0000 Original-Received: from localhost ([127.0.0.1]:60726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qBvFb-0008V0-A5 for submit@debbugs.gnu.org; Wed, 21 Jun 2023 06:39:47 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]:17092) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qBvFZ-0008Uo-Po for 64133@debbugs.gnu.org; Wed, 21 Jun 2023 06:39:46 -0400 Original-Received: (qmail 65077 invoked by uid 3782); 21 Jun 2023 12:39:40 +0200 Original-Received: from acm.muc.de (pd953aea6.dip0.t-ipconnect.de [217.83.174.166]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 21 Jun 2023 12:39:39 +0200 Original-Received: (qmail 4446 invoked by uid 1000); 21 Jun 2023 10:39:39 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de 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:263797 Archived-At: Hello again, Jeff. On Mon, Jun 19, 2023 at 11:46:32 +0000, Alan Mackenzie wrote: > On Sun, Jun 18, 2023 at 12:23:58 -0500, Jeff Norden wrote: > > The only reason the minibuffer-read affects things is timing. This > > seems obvious now, but somehow it didn't occur to me until after I > > sent the previous message. If I do > > ..wait a few seconds.. > > then the syntax does *not* change to brace-list. I tried changing > > c-progress-interval, but that didn't seem to affect things. Maybe > > there is another timer, or maybe a race condition involved somehow. > No, I think it really is the cache bug I mentioned in my last post. > Caches are wonderful things when they work properly, but the utter devil > to debug when they don't. > I've currently got a CC Mode version with this cache corrected, such > that it parses your test file correctly, but I want to make sure the > correction is correct before I send you a patch and release the fix. > I'll be back again soon. OK, here's the patch which I think fixes the bug completely. Would you please apply this patch to your ..../lisp/progmodes/cc-engine.el, byte-compile (or native-compile) that file, and then try it out on your real code. (In the unlikely event that you want help with the patching or compilation, feel free to send me personal email.) Then, please confirm that the bug is fixed, or tell me what's still not working. Thanks! diff -r 2cd57c62754a cc-engine.el --- a/cc-engine.el Sat Jun 17 12:45:10 2023 +0000 +++ b/cc-engine.el Wed Jun 21 10:27:21 2023 +0000 @@ -12816,11 +12816,19 @@ (defvar c-laomib-cache nil) (make-variable-buffer-local 'c-laomib-cache) -(defun c-laomib-get-cache (containing-sexp) - ;; Get an element from `c-laomib-cache' matching CONTAINING-SEXP. +(defun c-laomib-get-cache (containing-sexp start) + ;; Get an element from `c-laomib-cache' matching CONTAINING-SEXP, and which + ;; is suitable for start postiion START. ;; Return that element or nil if one wasn't found. - (let ((elt (assq containing-sexp c-laomib-cache))) - (when elt + (let ((ptr c-laomib-cache) + elt) + (while + (and ptr + (setq elt (car ptr)) + (or (not (eq (car elt) containing-sexp)) + (< start (car (cddr elt))))) + (setq ptr (cdr ptr))) + (when ptr ;; Move the fetched `elt' to the front of the cache. (setq c-laomib-cache (delq elt c-laomib-cache)) (push elt c-laomib-cache) @@ -12832,18 +12840,26 @@ ;; the components of the new element (see comment for `c-laomib-cache'). ;; The return value is of no significance. (when lim - (let ((old-elt (assq lim c-laomib-cache)) - ;; (elt (cons containing-sexp (cons start nil))) + (let (old-elt (new-elt (list lim start end result)) big-ptr (cur-ptr c-laomib-cache) - togo (size 0) cur-size - ) - (if old-elt (setq c-laomib-cache (delq old-elt c-laomib-cache))) + togo (size 0) cur-size) + + ;; If there is an elt which overlaps with the new element, remove it. + (while + (and cur-ptr + (setq old-elt (car cur-ptr)) + (or (not (eq (car old-elt) lim)) + (not (and (> start (car (cddr old-elt))) + (<= start (cadr old-elt)))))) + (setq cur-ptr (cdr cur-ptr))) + (when (and cur-ptr old-elt) + (setq c-laomib-cache (delq old-elt c-laomib-cache))) (while (>= (length c-laomib-cache) 4) ;; We delete the least recently used elt which doesn't enclose START, - ;; or.. + ;; or ... (dolist (elt c-laomib-cache) (if (or (<= start (cadr elt)) (> start (car (cddr elt)))) @@ -12851,8 +12867,10 @@ ;; ... delete the least recently used elt which isn't the biggest. (when (not togo) + (setq cur-ptr c-laomib-cache) (while (cdr cur-ptr) - (setq cur-size (- (nth 2 (cadr cur-ptr)) (car (cadr cur-ptr)))) + (setq cur-size (- (cadr (cadr cur-ptr)) + (car (cddr (cadr cur-ptr))))) (when (> cur-size size) (setq size cur-size big-ptr cur-ptr)) @@ -13044,7 +13062,7 @@ (goto-char pos) (when (eq braceassignp 'dontknow) (let* ((cache-entry (and containing-sexp - (c-laomib-get-cache containing-sexp))) + (c-laomib-get-cache containing-sexp pos))) (lim2 (or (cadr cache-entry) lim)) sub-bassign-p) (if cache-entry @@ -13066,6 +13084,8 @@ ) (setq braceassignp (nth 3 cache-entry)) (goto-char (nth 2 cache-entry))) + (c-laomib-put-cache containing-sexp + start (point) sub-bassign-p) (setq braceassignp sub-bassign-p))) (t)) > > Hope this helps, > > -Jeff -- Alan Mackenzie (Nuremberg, Germany).