GNU bug report logs - #36397
CC Mode 5.34 (C++//l); Bad highlighting on inserting a string

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 36397 <at> debbugs.gnu.org
Subject: bug#36397: CC Mode 5.34 (C++//l); Bad highlighting on inserting a string
Date: Fri, 19 Jul 2019 10:43:22 +0000

Hello, Richard.

On Thu, Jul 18, 2019 at 10:19:42 +0100, Richard Copley wrote:
> On Wed, 17 Jul 2019 at 11:49, Alan Mackenzie <acm <at> muc.de> wrote:

>     On Fri, Jun 28, 2019 at 14:28:29 +0100, Richard Copley wrote:
>     > On Thu, 27 Jun 2019 at 12:11, Alan Mackenzie <acm <at> muc.de> wrote:

>     > > There are more than just that one coding error in this area,
>     > > and I'd like to fix them all at the same time.  In the
>     > > meantime, please try out this patch, and let me know how well
>     > > it works.  Thanks!

>     > That seems to work just fine, thank you. I'll keep it in my
>     > local clone of the master branch for the time being.  Thank you.

>     OK.  I think this bug is now fixed in the current master, in
>     particular after the commit
>     585fb957399f21a93cbfabd182b76262466797e3 from yesterday, "CC Mode:
>     allow bogusly "adjacent" double quote marks to pair up
>     syntactically".

>     I've had several bugs with overlapping causes to fix, so apologies that
>     bug #36397 kind of got pushed down the stack.

>     Could I ask you, please, to check whether the bug is indeed fixed in
>     master, and let me know.  If it is, I can then close the bug.

> Thanks Alan,
> There are still some issues with fontifying strings. I reverted the patch
> you provided earlier and rebuilt from master.

> >>From Emacs -Q, visit an empty or absent file in C++ mode and type the
> following (two slashes, a space and a double quote):

> // "

> Actual: The double quote is highlighted in font-lock-warning-face.
> Expected: font-lock-comment-face.

Thanks for spotting that.  There were a couple of bugs left concerning
unterminated comments (i.e. ones which just "ended" at EOB, rather than
having a */ or NL to terminate them).

I think the following patch fixes them.  Would you try it out, please,
and confirm to me that this does fix that bug, or tell me about any
further faults you see.  Then, hopefully, we can finally close this bug.

Thanks!


diff -r 7bee52fd72a1 cc-engine.el
--- a/cc-engine.el	Wed Jul 17 09:23:34 2019 +0000
+++ b/cc-engine.el	Fri Jul 19 10:18:11 2019 +0000
@@ -2868,6 +2868,7 @@
 ;; element is a list (HERE STATE END)), where HERE is the buffer position the
 ;; function was called for, STATE is the `parse-partial-sexp' state there, and
 ;; END is the end of the literal enclosing HERE, if any, or nil otherwise.
+;; N.B. END will be nil if the literal ends at EOB without a delimiter.
 
 (defun c-full-trim-near-cache ()
   ;; Remove stale entries in `c-full-lit-near-cache', i.e. those whose END
@@ -2936,7 +2937,8 @@
   ;; (STATE)                    otherwise,
   ;; where STATE is the parsing state at HERE, TYPE is the type of the literal
   ;; enclosing HERE, (one of 'string, 'c, 'c++) and (BEG . END) is the
-  ;; boundaries of that literal (including the delimiters).
+  ;; boundaries of that literal (including the delimiters), with END being nil
+  ;; if there is no end delimiter (i.e. the literal ends at EOB).
   ;;
   ;; 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.
@@ -2955,6 +2957,7 @@
 	       (base (car elt))
 	       (near-base base)
 	       (s (cadr elt))
+	       s1
 	       (end (car (cddr elt)))
 	       far-base-and-state far-base far-s ty start)
 	  (if (or
@@ -2995,12 +2998,17 @@
 		      (t 'c)))
 	    (setq start (nth 8 s))
 	    (unless end
-	      (parse-partial-sexp here (point-max)
-				  nil	     ; TARGETDEPTH
-				  nil	     ; STOPBEFORE
-				  s	     ; OLDSTATE
-				  'syntax-table) ; stop at end of literal
-	      (setq end (point)))
+	      (setq s1 (parse-partial-sexp here (point-max)
+					   nil		  ; TARGETDEPTH
+					   nil		  ; STOPBEFORE
+					   s		  ; OLDSTATE
+					   'syntax-table)); stop at EO literal
+	      (unless (or (nth 3 s1)			  ; still in a string
+			  (and (nth 4 s1)
+			       (not (eq (nth 7 s1) 'syntax-table)))) ; still
+								     ; in a
+								     ; comment
+		(setq end (point))))
 	    (unless (eq near-base here)
 	      (c-full-put-near-cache-entry here s end))
 	    (list s ty (cons start end)))
@@ -5454,8 +5462,11 @@
 						   s
 						   'syntax-table)
 			       (point)))))
-	    (let ((pp-to-lit (c-full-pp-to-literal pos not-in-delimiter)))
-	      (car (cddr pp-to-lit))))))
+	    (let* ((pp-to-lit (c-full-pp-to-literal pos not-in-delimiter))
+		   (limits (car (cddr pp-to-lit))))
+	      (if (and limits (null (cdr limits)))
+		  (cons (car limits) (point-max))
+		limits)))))
       (cond
        (lit-limits)
 
diff -r 7bee52fd72a1 cc-mode.el
--- a/cc-mode.el	Wed Jul 17 09:23:34 2019 +0000
+++ b/cc-mode.el	Fri Jul 19 10:18:11 2019 +0000
@@ -1509,7 +1509,9 @@
 			   (or (not (nth 3 s))
 			       (not (memq (char-before) c-string-delims))))))
 	     ;; We're at the start of a string.
-	     (memq (char-before) c-string-delims)))
+	     (and (memq (char-before) c-string-delims)
+		  (not (nth 4 s)))))	; Check we're actually out of the
+					; comment. not stuck at EOB
 	(unless (and (c-major-mode-is 'c++-mode)
 		     (c-maybe-re-mark-raw-string))
 	  (if (c-unescaped-nls-in-string-p (1- (point)))


-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.