From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#11749: Acknowledgement (24.1; C-mode indentation gives wrong-type-argument error.) Date: Sun, 14 Oct 2012 17:06:50 +0000 Message-ID: <20121014170650.GA3766@acm.acm> References: <50447C94.2040402@cua.dk> <20120905204821.GA3620@acm.acm> <87ipbqpkb7.fsf@maru.md5i.com> <20120908211451.GA22477@acm.acm> <20121007105951.GA3194@acm.acm> <20121010200025.GA3449@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1350234786 15323 80.91.229.3 (14 Oct 2012 17:13:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Oct 2012 17:13:06 +0000 (UTC) Cc: "11749@debbugs.gnu.org" <11749@debbugs.gnu.org>, Kim Storm To: Michael Welsh Duggan Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 14 19:13:13 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TNRkW-0006DB-1Z for geb-bug-gnu-emacs@m.gmane.org; Sun, 14 Oct 2012 19:13:12 +0200 Original-Received: from localhost ([::1]:41711 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TNRkP-00022j-8O for geb-bug-gnu-emacs@m.gmane.org; Sun, 14 Oct 2012 13:13:05 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TNRkM-00022P-Ps for bug-gnu-emacs@gnu.org; Sun, 14 Oct 2012 13:13:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TNRkL-0006vp-HA for bug-gnu-emacs@gnu.org; Sun, 14 Oct 2012 13:13:02 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33806) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TNRkJ-0006vW-IP; Sun, 14 Oct 2012 13:12:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TNRlJ-0002T3-HK; Sun, 14 Oct 2012 13:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sun, 14 Oct 2012 17:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11749 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 11749-submit@debbugs.gnu.org id=B11749.13502347989423 (code B ref 11749); Sun, 14 Oct 2012 17:14:01 +0000 Original-Received: (at 11749) by debbugs.gnu.org; 14 Oct 2012 17:13:18 +0000 Original-Received: from localhost ([127.0.0.1]:44057 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TNRkb-0002Rv-Bl for submit@debbugs.gnu.org; Sun, 14 Oct 2012 13:13:17 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:29568 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TNRkY-0002Rm-3U for 11749@debbugs.gnu.org; Sun, 14 Oct 2012 13:13:16 -0400 Original-Received: (qmail 13650 invoked by uid 3782); 14 Oct 2012 17:12:09 -0000 Original-Received: from acm.muc.de (pD951A880.dip.t-dialin.net [217.81.168.128]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 14 Oct 2012 19:12:07 +0200 Original-Received: (qmail 4736 invoked by uid 1000); 14 Oct 2012 17:06:50 -0000 Content-Disposition: inline In-Reply-To: <20121010200025.GA3449@acm.acm> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:65600 Archived-At: Hi, Michael, On Wed, Oct 10, 2012 at 08:00:25PM +0000, Alan Mackenzie wrote: > On Tue, Oct 09, 2012 at 10:05:07AM -0400, Michael Welsh Duggan wrote: > > Alan Mackenzie writes: [ .... ] > > > I have found the bug which is causing (most of) these dings, though I > > > don't think it is the one which caused Kim's original bug. Could you try > > > out the patch below, please. (I have also enhanced/corrected the > > > debugging routines a bit, too.) > > Still doesn't seem to help much here. I have attached a file which > > reliably causes a cache failure. I have attached the smallest file of > > the set of files I am working on that causes this particular problem. > > Load the attached file and toggle on parse state debugging. Then scroll > > to the bottom of the file. (Use C-v multiple times, or just M->.) One > > reason I have attached this file is that it only triggers the warning > > message once. Most of my larger files cause this to happen quite a lot. > What is happening in this file is another bug, arising from historical > assumptions which are no longer valid. > The "from scratch" calculation notes that the starting scanning position > would be a long way (>5000) back, hence it tries going back to the second > "beginning-of-defun" to get a top-level starting point. This > "beginning-of-defun" is a pure "brace in column zero" test. > This doesn't work in C++ when constructs inside a namespace have braces > at column zero, something I believe has become very common in recent > years. Namespaces didn't exist in C++ when c-parse-state was originally > written. > Obviously this optimisation is no longer valid. I wouldn't be surprised > if it has caused quite a bit of buggy behaviour. I'll need to think it > over for a few days to decide what to do. The only reasonable thing to do is to disable the heuristic for C++ Mode. This is what the patch below now does. Could you try it out as usual, please. Thanks! diff -r ac6584d14c06 cc-engine.el --- a/cc-engine.el Sun Sep 09 11:15:13 2012 +0000 +++ b/cc-engine.el Sun Oct 14 17:02:08 2012 +0000 @@ -2560,8 +2560,11 @@ start-point cache-pos))) ;; Might we be better off starting from the top level, two defuns back, - ;; instead? - (when (> how-far c-state-cache-too-far) + ;; instead? This heuristic no longer works well in C++, where + ;; declarations inside namespace brace blocks are frequently placed at + ;; column zero. + (when (and (not (c-major-mode-is 'c++-mode)) + (> how-far c-state-cache-too-far)) (setq BOD-pos (c-get-fallback-scan-pos here)) ; somewhat EXPENSIVE!!! (if (< (- here BOD-pos) how-far) (setq strategy 'BOD @@ -2648,17 +2651,19 @@ ;; If we're essentially repeating a fruitless search, just give up. (unless (and c-state-brace-pair-desert (eq cache-pos (car c-state-brace-pair-desert)) + (> from (car c-state-brace-pair-desert)) (<= from (cdr c-state-brace-pair-desert))) - ;; DESERT-LIM. Only search what we absolutely need to, + ;; DESERT-LIM. Avoid repeated searching through the cached desert. (let ((desert-lim (and c-state-brace-pair-desert (eq cache-pos (car c-state-brace-pair-desert)) + (>= from (cdr c-state-brace-pair-desert)) (cdr c-state-brace-pair-desert))) ;; CACHE-LIM. This limit will be necessary when an opening ;; paren at `cache-pos' has just had its matching close paren - ;; inserted. `cache-pos' continues to be a search bound, even - ;; though the algorithm below would skip over the new paren - ;; pair. + ;; inserted into the buffer. `cache-pos' continues to be a + ;; search bound, even though the algorithm below would skip + ;; over the new paren pair. (cache-lim (and cache-pos (< cache-pos from) cache-pos))) (narrow-to-region (cond @@ -3354,13 +3359,19 @@ (fset 'c-real-parse-state (symbol-function 'c-parse-state))) (cc-bytecomp-defun c-real-parse-state) +(defvar c-parse-state-point nil) (defvar c-parse-state-state nil) (make-variable-buffer-local 'c-parse-state-state) (defun c-record-parse-state-state () + (setq c-parse-state-point (point)) (setq c-parse-state-state (mapcar (lambda (arg) - (cons arg (symbol-value arg))) + (let ((val (symbol-value arg))) + (cons arg + (if (consp val) + (copy-tree val) + val)))) '(c-state-cache c-state-cache-good-pos c-state-nonlit-pos-cache @@ -3373,7 +3384,8 @@ c-state-point-min-lit-start c-state-min-scan-pos c-state-old-cpp-beg - c-state-old-cpp-end)))) + c-state-old-cpp-end + c-parse-state-point)))) (defun c-replay-parse-state-state () (message (concat "(setq " @@ -3416,7 +3428,8 @@ (message "Old state:") (c-replay-parse-state-state)) (c-record-parse-state-state) - res1)) + res2 ; res1 correct a cascading series of errors ASAP + )) (defun c-toggle-parse-state-debug (&optional arg) (interactive "P") > > -- > > Michael Welsh Duggan > > (mwd@cert.org) -- Alan Mackenzie (Nuremberg, Germany).