bug#15728: 24.3.50; cc-mode incorrectly parses particular macro

bug#15728: 24.3.50; cc-mode incorrectly parses particular macro

[Dima Kogan]

I have the following source file:

=========================================================================
int f(void)
{
#define A(b)								\
  int abc ## b;								\
    g()
}
=========================================================================

This indentation is what the latest emacs thinks is correct. Note that
the g() line is indented ahead of the 'int abc' line. This is wrong;
they should have the same indentation. Indeed this is what happens with
emacs23.

In the latest emacs the syntax parser thinks the g() line is
'statement-cont', instead of 'statement'; this is directly related to
the issue. Furthermore, the 'abc ## b' construct is what's confusing the
parser. Removing the '##' makes it parse correctly again.

I'm observing this issue with all emacs24 builds I've tried, with 'emacs
-Q'.

bug#15728: bug #15728: 24.3.50; cc-mode incorrectly parses particular macro

[Alan Mackenzie]

Hello, Dima

Dima Kogan <dima@secretsauce.net> writes:
> I have the following source file:

> =========================================================================
> int f(void)
> {
> #define A(b)                                                            \
>   int abc ## b;                                                         \
>     g()
> }
> =========================================================================

> This indentation is what the latest emacs thinks is correct. Note that
> the g() line is indented ahead of the 'int abc' line. This is wrong;
> they should have the same indentation. Indeed this is what happens with
> emacs23.

> In the latest emacs the syntax parser thinks the g() line is
> 'statement-cont', instead of 'statement'; this is directly related to
> the issue. Furthermore, the 'abc ## b' construct is what's confusing the
> parser. Removing the '##' makes it parse correctly again.

Funnily enough, it seems to work OK if the macro isn't written inside a
function.

> I'm observing this issue with all emacs24 builds I've tried, with 'emacs
> -Q'.

Thanks for the bug report, and thanks even more for making it crisp and
concise.

I think the following patch should fix it.  Would you try it out,
please, and let me know how well it works.



diff -r c21bf2a4a8b8 cc-engine.el
--- a/cc-engine.el	Sun Oct 20 14:10:45 2013 +0000
+++ b/cc-engine.el	Sun Oct 27 13:31:43 2013 +0000
@@ -1266,12 +1266,15 @@
 	      ;; looking for more : and ?.
 	      (setq c-maybe-labelp nil
 		    skip-chars (substring c-stmt-delim-chars 0 -2)))
-	     ;; At a CPP construct?
-	     ((and c-opt-cpp-symbol (looking-at c-opt-cpp-symbol)
-		   (save-excursion
-		     (forward-line 0)
-		     (looking-at c-opt-cpp-prefix)))
-	      (c-end-of-macro))
+	     ;; At a CPP construct or a "#" or "##" operator?
+	     ((and c-opt-cpp-symbol (looking-at c-opt-cpp-symbol))
+	      (if (save-excursion
+		    (skip-chars-backward " \t")
+		    (and (bolp)
+			 (or (bobp)
+			     (not (eq (char-before (1- (point))) ?\\)))))
+		  (c-end-of-macro)
+		(skip-chars-forward c-opt-cpp-symbol)))
 	     ((memq (char-after) non-skip-list)
 	      (throw 'done (point)))))
 	  ;; In trailing space after an as yet undetected virtual semicolon?



-- 
Alan Mackenzie (Nuremberg, Germany).

bug#15728: bug #15728: 24.3.50; cc-mode incorrectly parses particular macro

[Dima Kogan]

Alan Mackenzie <acm@muc.de> writes:

> I think the following patch should fix it.  Would you try it out,
> please, and let me know how well it works.

Hi Alan. I tried the patch and it does solve the issue for me. Thank you
very much for fixing this issue so quickly.

dima

bug#15728: bug #15728: 24.3.50; cc-mode incorrectly parses particular macro

[Alan Mackenzie]

Bug fixed.

-- 
Alan Mackenzie (Nuremberg, Germany).