all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Dietrich Epp <dietrich@zdome.net>
Cc: 13244@debbugs.gnu.org
Subject: bug#13244: cc-mode indentation fails depending on the phase of the moon
Date: Mon, 11 Mar 2013 20:57:37 +0000	[thread overview]
Message-ID: <20130311205737.GB24515@acm.acm> (raw)
In-Reply-To: <20121227162054.GA3235@acm.acm>

Hello again, Dietrich.

On Thu, Dec 27, 2012 at 04:20:54PM +0000, Alan Mackenzie wrote:
> >This bug is weird.  I couldn't use auto-indentation in a certain file.
> >I tried restarting Emacs, behavior persists.  I upgraded to the latest
> >version from Bzr, behavior persists.  I created a new account with no
> >.emacs file and tried from there, behavior persists.  In comparison,
> >indentation works correctly in the Emacs that in the current Debian
> >Wheezy repository, which is 24.3.50.1.

> >Trying to automatically indent code inside the last function in the
> >attached file fails.  It succeeds if I make almost any modification to
> >code above the last function in the file -- it could be something as
> >minor as adding a space on an empty line, but changing text in the
> >comments seems to have no effect.  Indentation works in every function
> >but the last one (or any one you create below it).

> >The point at which indentation breaks is somewhere very close to the
> >bottom of the file, I deleted code from the bottom of the file until I
> >found the location where it breaks.

> What is happening is this: CC Mode maintains a cache of "safe positions"
> (i.e. positions not in a string or comment) approximately every 3000
> bytes.  By pure chance, one of these supposed positions in your file is
> at pos. 21002, which happens to be between the "/" and the "*" of the
> comment opener on L836.  This position isn't safe at all, and is found
> due to a bug in a low level scanning routine (`parse-partial-sexp') in
> Emacs.

> Furthermore, that comment contains an "unbalanced" "'".  So when CC Mode
> scans forward from that supposed safe position, it finds the "'" and
> thinks it's inside a string.  This is why indentation isn't working in
> your file after that comment.

> As you've noted, the slightest change to the buffer and the error no
> longer happens (since the "safe" position is no longer inside the
> comment opener).

> Thank you very much indeed for taking the trouble to report this arcane
> bug.  We actually noticed the possibility of this bug in December 2011
> and discussed it a bit, but nobody actually got around to fixing it
> then.  Maybe we should now.


I've got a patch which should fix this problem.  Maybe you could apply
the patch to Emacs and check that it works properly.  Just in case you
don't have the critical file any more, I could send that to you too.  :-)

Again, thanks for the bug report.



diff -r bc6aa6ba14cc cc-engine.el
--- a/cc-engine.el	Wed Mar 06 12:02:31 2013 +0000
+++ b/cc-engine.el	Mon Mar 11 20:51:42 2013 +0000
@@ -2179,32 +2179,45 @@
 ;; reduced by buffer changes, and increased by invocations of
 ;; `c-state-literal-at'.  FIMXE!!!
 
-(defsubst c-state-pp-to-literal (from to)
+(defsubst c-state-pp-to-literal (from to &optional not-in-delimiter)
   ;; Do a parse-partial-sexp from FROM to TO, returning either
   ;;     (STATE TYPE (BEG . END))     if TO is in a literal; or
   ;;     (STATE)                      otherwise,
   ;; where STATE is the parsing state at TO, TYPE is the type of the literal
   ;; (one of 'c, 'c++, 'string) and (BEG . END) is the boundaries of the literal.
   ;;
+  ;; Unless NOT-IN-DELIMITER is non-nil, when TO is inside a two-character
+  ;; comment opener, this is recognized as being in a comment literal.
+  ;;
   ;; Only elements 3 (in a string), 4 (in a comment), 5 (following a quote),
   ;; 7 (comment type) and 8 (start of comment/string) (and possibly 9) of
   ;; STATE are valid.
   (save-excursion
     (let ((s (parse-partial-sexp from to))
-	  ty)
-      (when (or (nth 3 s) (nth 4 s))	; in a string or comment
+	  ty co-st)
+      (cond
+       ((or (nth 3 s) (nth 4 s))	; in a string or comment
 	(setq ty (cond
 		  ((nth 3 s) 'string)
-		  ((eq (nth 7 s) t) 'c++)
+		  ((nth 7 s) 'c++)
 		  (t 'c)))
 	(parse-partial-sexp (point) (point-max)
-			    nil			 ; TARGETDEPTH
-			    nil			 ; STOPBEFORE
-			    s			 ; OLDSTATE
-			    'syntax-table))	 ; stop at end of literal
-      (if ty
-	  `(,s ,ty (,(nth 8 s) . ,(point)))
-	`(,s)))))
+			    nil		   ; TARGETDEPTH
+			    nil		   ; STOPBEFORE
+			    s		   ; OLDSTATE
+			    'syntax-table) ; stop at end of literal
+	`(,s ,ty (,(nth 8 s) . ,(point))))
+
+       ((and (not not-in-delimiter)	; inside a comment starter
+	     (not (bobp))
+	     (progn (backward-char)
+		    (looking-at c-comment-start-regexp)))
+	(setq ty (if (looking-at c-block-comment-start-regexp) 'c 'c++)
+	      co-st (point))
+	(forward-comment 1)
+	`(,s ,ty (,co-st . ,(point))))
+
+       (t `(,s))))))
 
 (defun c-state-safe-place (here)
   ;; Return a buffer position before HERE which is "safe", i.e. outside any
@@ -3146,10 +3159,13 @@
   ;; This function is called from c-after-change.
 
   ;; The caches of non-literals:
-  (if (< here c-state-nonlit-pos-cache-limit)
-      (setq c-state-nonlit-pos-cache-limit here))
-  (if (< here c-state-semi-nonlit-pos-cache-limit)
-      (setq c-state-semi-nonlit-pos-cache-limit here))
+  ;; Note that we use "<=" for the possibility of the second char of a two-char
+  ;; comment opener being typed; this would invalidate any cache position at
+  ;; HERE.
+  (if (<= here c-state-nonlit-pos-cache-limit)
+      (setq c-state-nonlit-pos-cache-limit (1- here)))
+  (if (<= here c-state-semi-nonlit-pos-cache-limit)
+      (setq c-state-semi-nonlit-pos-cache-limit (1- here)))
 
   ;; `c-state-cache':
   ;; Case 1: if `here' is in a literal containing point-min, everything
@@ -4467,19 +4483,12 @@
 	   (lim (or lim (c-state-semi-safe-place pos)))
 	   (pp-to-lit (save-restriction
 			(widen)
-			(c-state-pp-to-literal lim pos)))
+			(c-state-pp-to-literal lim pos not-in-delimiter)))
 	   (state (car pp-to-lit))
 	   (lit-limits (car (cddr pp-to-lit))))
 
       (cond
        (lit-limits)
-       ((and (not not-in-delimiter)
-	     (not (elt state 5))
-	     (eq (char-before) ?/)
-	     (looking-at "[/*]")) ; FIXME!!! use c-line/block-comment-starter.  2008-09-28.
-	;; We're standing in a comment starter.
-	(backward-char 1)
-	(cons (point) (progn (c-forward-single-comment) (point))))
 
        (near
 	(goto-char pos)
diff -r bc6aa6ba14cc cc-fonts.el
--- a/cc-fonts.el	Wed Mar 06 12:02:31 2013 +0000
+++ b/cc-fonts.el	Mon Mar 11 20:51:42 2013 +0000
@@ -2449,7 +2449,7 @@
 	      (setq comment-beg nil))
 	    (setq region-beg comment-beg))
 
-      (if (eq (elt (parse-partial-sexp comment-beg (+ comment-beg 2)) 7) t)
+      (if (elt (parse-partial-sexp comment-beg (+ comment-beg 2)) 7)
 	  ;; Collect a sequence of doc style line comments.
 	  (progn
 	    (goto-char comment-beg)



-- 
Alan Mackenzie (Nuremberg, Germany).





      reply	other threads:[~2013-03-11 20:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-21  1:06 bug#13244: cc-mode indentation fails depending on the phase of the moon Dietrich Epp
2012-12-27 16:20 ` Alan Mackenzie
2013-03-11 20:57   ` Alan Mackenzie [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130311205737.GB24515@acm.acm \
    --to=acm@muc.de \
    --cc=13244@debbugs.gnu.org \
    --cc=dietrich@zdome.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.