GNU bug report logs - #42270
28.0.50; cc-mode indentation issue with attributes

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42270 in the body.
You can then email your comments to 42270 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; cc-mode indentation issue with attributes
Date: Wed, 8 Jul 2020 19:03:58 +0200

Hi:

Working in C++ I am getting this indentation difference when arguments
has attributes or not:

TaskDataAccesses(TaskDataAccessesInfo taskAccessInfo)
	: _lock(),
	  _accesses(),
	  _accessFragments(), _taskwaitFragments()
{
}


TaskDataAccesses(__attribute__((unused)) TaskDataAccessesInfo taskAccessInfo)
: _lock(),
_accesses(),
_accessFragments(), _taskwaitFragments()
{
}

The problem seems to be that in the first case the `:` indentation
symbol (C-c C-o) is recognised as `member-init-intro` (correct) but in
the second one it is detected as a `topmost-intro-cont` which is
actually wrong.

Best,
Ergus

In GNU Emacs 28.0.50 (build 10, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
of 2020-07-07 built on ergus
Repository revision: df3ece9d2ed61c9526dbf718e3c96d72bd53dccb
Repository branch: master
System Description: Debian GNU/Linux 10 (buster)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
'configure --prefix=/home/ergus/.local/ --with-mailutils'

Configured features:
XPM JPEG TIFF GIF PNG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY
LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS
LUCID X11 XDBE XIM MODULES THREADS PDUMPER GMP

Important settings:
 value of $LANG: en_GB.UTF-8
 locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
 tooltip-mode: t
 global-eldoc-mode: t
 eldoc-mode: t
 electric-indent-mode: t
 mouse-wheel-mode: t
 tool-bar-mode: t
 menu-bar-mode: t
 file-name-shadow-mode: t
 global-font-lock-mode: t
 font-lock-mode: t
 auto-composition-mode: t
 auto-encryption-mode: t
 auto-compression-mode: t
 line-number-mode: t
 transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search time-date subr-x seq
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils term/tmux term/xterm xterm byte-opt gv
bytecomp byte-compile cconv tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo x-toolkit x multi-tty make-network-process
emacs)

Memory information:
((conses 16 48788 5097)
(symbols 48 6074 1)
(strings 32 15630 1699)
(string-bytes 1 506737)
(vectors 16 7254)
(vector-slots 8 75610 8410)
(floats 8 22 231)
(intervals 56 180 0)
(buffers 992 10))

Message #8 received at 42270 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Ergus <spacibba <at> aol.com>
Cc: acm <at> muc.de, 42270 <at> debbugs.gnu.org
Subject: Re: bug#42270: 28.0.50; cc-mode indentation issue with attributes
Date: Sat, 5 Sep 2020 12:13:35 +0000

Hello, Ergus.

Thanks for the bug report.

On Wed, Jul 08, 2020 at 19:03:58 +0200, Ergus wrote:
> Hi:

> Working in C++ I am getting this indentation difference when arguments
> has attributes or not:

> TaskDataAccesses(TaskDataAccessesInfo taskAccessInfo)
> 	: _lock(),
> 	  _accesses(),
> 	  _accessFragments(), _taskwaitFragments()
> {
> }


> TaskDataAccesses(__attribute__((unused)) TaskDataAccessesInfo taskAccessInfo)
> : _lock(),
> _accesses(),
> _accessFragments(), _taskwaitFragments()
> {
> }

> The problem seems to be that in the first case the `:` indentation
> symbol (C-c C-o) is recognised as `member-init-intro` (correct) but in
> the second one it is detected as a `topmost-intro-cont` which is
> actually wrong.

Yes, indeed.  There were also problems with the fontification in similar
fragments, e.g.:

    TaskDataAccesses(foo((unused)) TaskDataAccessesInfo taskAccessInfo)
    : _lock(),
        _accesses(),
        _accessFragments(), _taskwaitFragments()
    {
    }

, where typing into "foo" removed the fontification from
"Task...unused))", which got replaced on the next redisplay (e.g. after
typing M-x).

I think the patch below fixes all these problems.  Would you please apply
it, rebuild CC Mode, load it, and try it out on your real source code.  A
fairly thorough test would be appreciated, here.  Then please let me know
if the bug is actually fixed, and whether there are any "strange things"
happening.  Thanks!

> Best,
> Ergus

> In GNU Emacs 28.0.50 (build 10, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
>  of 2020-07-07 built on ergus
> Repository revision: df3ece9d2ed61c9526dbf718e3c96d72bd53dccb
> Repository branch: master
> System Description: Debian GNU/Linux 10 (buster)



diff -r 877c4ad9dae8 cc-engine.el
--- a/cc-engine.el	Sat Jul 04 16:23:06 2020 +0000
+++ b/cc-engine.el	Sat Sep 05 11:53:51 2020 +0000
@@ -2243,7 +2243,7 @@
 
 	     ((and c-opt-cpp-prefix
 		   (looking-at c-noise-macro-name-re))
-	      ;; Skip over a noise macro.
+	      ;; Skip over a noise macro without parens.
 	      (goto-char (match-end 1))
 	      (not (eobp)))
 
@@ -9141,6 +9141,12 @@
 				  (catch 'is-function
 				    (while
 					(progn
+					  (while
+					      (cond
+					       ((looking-at c-decl-hangon-key)
+						(c-forward-keyword-clause 1))
+					       ((looking-at c-noise-macro-with-parens-name-re)
+						(c-forward-noise-clause))))
 					  (if (eq (char-after) ?\))
 					      (throw 'is-function t))
 					  (setq cdd-got-type (c-forward-type))
@@ -9789,6 +9795,16 @@
 				  (save-excursion
 				    (goto-char after-paren-pos)
 				    (c-forward-syntactic-ws)
+				    (progn
+				      (while
+					  (cond
+					   ((and
+					     c-opt-cpp-prefix
+					     (looking-at c-noise-macro-with-parens-name-re))
+					    (c-forward-noise-clause))
+					   ((looking-at c-decl-hangon-key)
+					    (c-forward-keyword-clause 1))))
+				      t)
 				    (or (c-forward-type)
 					;; Recognize a top-level typeless
 					;; function declaration in C.
diff -r 877c4ad9dae8 cc-mode.el
--- a/cc-mode.el	Sat Jul 04 16:23:06 2020 +0000
+++ b/cc-mode.el	Sat Sep 05 11:53:51 2020 +0000
@@ -2236,7 +2236,8 @@
 (defun c-fl-decl-end (pos)
   ;; If POS is inside a declarator, return the end of the token that follows
   ;; the declarator, otherwise return nil.  POS being in a literal does not
-  ;; count as being in a declarator (on pragmatic grounds).
+  ;; count as being in a declarator (on pragmatic grounds).  POINT is not
+  ;; preserved.
   (goto-char pos)
   (let ((lit-start (c-literal-start))
 	enclosing-attribute pos1)
@@ -2249,12 +2250,31 @@
 	(let ((lim (save-excursion
 		     (and (c-beginning-of-macro)
 			  (progn (c-end-of-macro) (point))))))
-	  (when (and (c-forward-declarator lim)
-		     (or (not (eq (char-after) ?\())
-			 (c-go-list-forward nil lim))
-		     (eq (c-forward-token-2 1 nil lim) 0))
-	    (c-backward-syntactic-ws)
-	    (point)))))))
+	  (and (c-forward-declarator lim)
+	       (if (eq (char-after) ?\()
+		   (and
+		    (c-go-list-forward nil lim)
+		    (progn (c-forward-syntactic-ws lim)
+			   (not (eobp)))
+		    (progn
+		      (if (looking-at c-symbol-char-key)
+			  ;; Deal with baz (foo((bar)) type var), where
+			  ;; foo((bar)) is not semantically valid.  The result
+			  ;; must be after var).
+			  (and
+			   (goto-char pos)
+			   (setq pos1 (c-on-identifier))
+			   (goto-char pos1)
+			   (progn
+			     (c-backward-syntactic-ws)
+			     (eq (char-before) ?\())
+			   (c-fl-decl-end (1- (point))))
+			(c-backward-syntactic-ws)
+			(point))))
+		 (and (progn (c-forward-syntactic-ws lim)
+			     (not (eobp)))
+		      (c-backward-syntactic-ws)
+		      (point)))))))))
 
 (defun c-change-expand-fl-region (beg end old-len)
   ;; Expand the region (c-new-BEG c-new-END) to an after-change font-lock
diff -r 877c4ad9dae8 cc-vars.el
--- a/cc-vars.el	Sat Jul 04 16:23:06 2020 +0000
+++ b/cc-vars.el	Sat Sep 05 11:53:51 2020 +0000
@@ -1668,7 +1668,8 @@
 like \"INLINE\" which are syntactic noise.  Such a macro/extension is complete
 in itself, never having parentheses.  All these names must be syntactically
 valid identifiers.  Alternatively, this variable may be a regular expression
-which matches the names of such macros.
+which matches the names of such macros, in which case it must have a submatch
+1 which matches the actual noise macro name.
 
 If you change this variable's value, call the function
 `c-make-noise-macro-regexps' to set the necessary internal variables (or do
@@ -1683,7 +1684,8 @@
 which optionally have arguments in parentheses, and which expand to nothing.
 All these names must be syntactically valid identifiers.  These are recognized
 by CC Mode only in declarations.  Alternatively, this variable may be a
-regular expression which matches the names of such macros.
+regular expression which matches the names of such macros, in which case it
+must have a submatch 1 which matches the actual noise macro name.
 
 If you change this variable's value, call the function
 `c-make-noise-macro-regexps' to set the necessary internal variables (or do


-- 
Alan Mackenzie (Nuremberg, Germany).

Message #11 received at 42270 <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 42270 <at> debbugs.gnu.org
Subject: Re: bug#42270: 28.0.50; cc-mode indentation issue with attributes
Date: Mon, 7 Sep 2020 12:04:45 +0200

Hi Alan:

I will try it now and give you some feed back this week.

Very thanks,


On Sat, Sep 05, 2020 at 12:13:35PM +0000, Alan Mackenzie wrote:
>Hello, Ergus.
>
>Thanks for the bug report.
>
>On Wed, Jul 08, 2020 at 19:03:58 +0200, Ergus wrote:
>> Hi:
>
>> Working in C++ I am getting this indentation difference when arguments
>> has attributes or not:
>
>> TaskDataAccesses(TaskDataAccessesInfo taskAccessInfo)
>> 	: _lock(),
>> 	  _accesses(),
>> 	  _accessFragments(), _taskwaitFragments()
>> {
>> }
>
>
>> TaskDataAccesses(__attribute__((unused)) TaskDataAccessesInfo taskAccessInfo)
>> : _lock(),
>> _accesses(),
>> _accessFragments(), _taskwaitFragments()
>> {
>> }
>
>> The problem seems to be that in the first case the `:` indentation
>> symbol (C-c C-o) is recognised as `member-init-intro` (correct) but in
>> the second one it is detected as a `topmost-intro-cont` which is
>> actually wrong.
>
>Yes, indeed.  There were also problems with the fontification in similar
>fragments, e.g.:
>
>    TaskDataAccesses(foo((unused)) TaskDataAccessesInfo taskAccessInfo)
>    : _lock(),
>        _accesses(),
>        _accessFragments(), _taskwaitFragments()
>    {
>    }
>
>, where typing into "foo" removed the fontification from
>"Task...unused))", which got replaced on the next redisplay (e.g. after
>typing M-x).
>
>I think the patch below fixes all these problems.  Would you please apply
>it, rebuild CC Mode, load it, and try it out on your real source code.  A
>fairly thorough test would be appreciated, here.  Then please let me know
>if the bug is actually fixed, and whether there are any "strange things"
>happening.  Thanks!
>
>> Best,
>> Ergus
>
>> In GNU Emacs 28.0.50 (build 10, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
>>  of 2020-07-07 built on ergus
>> Repository revision: df3ece9d2ed61c9526dbf718e3c96d72bd53dccb
>> Repository branch: master
>> System Description: Debian GNU/Linux 10 (buster)
>
>
>
>diff -r 877c4ad9dae8 cc-engine.el
>--- a/cc-engine.el	Sat Jul 04 16:23:06 2020 +0000
>+++ b/cc-engine.el	Sat Sep 05 11:53:51 2020 +0000
>@@ -2243,7 +2243,7 @@
>
> 	     ((and c-opt-cpp-prefix
> 		   (looking-at c-noise-macro-name-re))
>-	      ;; Skip over a noise macro.
>+	      ;; Skip over a noise macro without parens.
> 	      (goto-char (match-end 1))
> 	      (not (eobp)))
>
>@@ -9141,6 +9141,12 @@
> 				  (catch 'is-function
> 				    (while
> 					(progn
>+					  (while
>+					      (cond
>+					       ((looking-at c-decl-hangon-key)
>+						(c-forward-keyword-clause 1))
>+					       ((looking-at c-noise-macro-with-parens-name-re)
>+						(c-forward-noise-clause))))
> 					  (if (eq (char-after) ?\))
> 					      (throw 'is-function t))
> 					  (setq cdd-got-type (c-forward-type))
>@@ -9789,6 +9795,16 @@
> 				  (save-excursion
> 				    (goto-char after-paren-pos)
> 				    (c-forward-syntactic-ws)
>+				    (progn
>+				      (while
>+					  (cond
>+					   ((and
>+					     c-opt-cpp-prefix
>+					     (looking-at c-noise-macro-with-parens-name-re))
>+					    (c-forward-noise-clause))
>+					   ((looking-at c-decl-hangon-key)
>+					    (c-forward-keyword-clause 1))))
>+				      t)
> 				    (or (c-forward-type)
> 					;; Recognize a top-level typeless
> 					;; function declaration in C.
>diff -r 877c4ad9dae8 cc-mode.el
>--- a/cc-mode.el	Sat Jul 04 16:23:06 2020 +0000
>+++ b/cc-mode.el	Sat Sep 05 11:53:51 2020 +0000
>@@ -2236,7 +2236,8 @@
> (defun c-fl-decl-end (pos)
>   ;; If POS is inside a declarator, return the end of the token that follows
>   ;; the declarator, otherwise return nil.  POS being in a literal does not
>-  ;; count as being in a declarator (on pragmatic grounds).
>+  ;; count as being in a declarator (on pragmatic grounds).  POINT is not
>+  ;; preserved.
>   (goto-char pos)
>   (let ((lit-start (c-literal-start))
> 	enclosing-attribute pos1)
>@@ -2249,12 +2250,31 @@
> 	(let ((lim (save-excursion
> 		     (and (c-beginning-of-macro)
> 			  (progn (c-end-of-macro) (point))))))
>-	  (when (and (c-forward-declarator lim)
>-		     (or (not (eq (char-after) ?\())
>-			 (c-go-list-forward nil lim))
>-		     (eq (c-forward-token-2 1 nil lim) 0))
>-	    (c-backward-syntactic-ws)
>-	    (point)))))))
>+	  (and (c-forward-declarator lim)
>+	       (if (eq (char-after) ?\()
>+		   (and
>+		    (c-go-list-forward nil lim)
>+		    (progn (c-forward-syntactic-ws lim)
>+			   (not (eobp)))
>+		    (progn
>+		      (if (looking-at c-symbol-char-key)
>+			  ;; Deal with baz (foo((bar)) type var), where
>+			  ;; foo((bar)) is not semantically valid.  The result
>+			  ;; must be after var).
>+			  (and
>+			   (goto-char pos)
>+			   (setq pos1 (c-on-identifier))
>+			   (goto-char pos1)
>+			   (progn
>+			     (c-backward-syntactic-ws)
>+			     (eq (char-before) ?\())
>+			   (c-fl-decl-end (1- (point))))
>+			(c-backward-syntactic-ws)
>+			(point))))
>+		 (and (progn (c-forward-syntactic-ws lim)
>+			     (not (eobp)))
>+		      (c-backward-syntactic-ws)
>+		      (point)))))))))
>
> (defun c-change-expand-fl-region (beg end old-len)
>   ;; Expand the region (c-new-BEG c-new-END) to an after-change font-lock
>diff -r 877c4ad9dae8 cc-vars.el
>--- a/cc-vars.el	Sat Jul 04 16:23:06 2020 +0000
>+++ b/cc-vars.el	Sat Sep 05 11:53:51 2020 +0000
>@@ -1668,7 +1668,8 @@
> like \"INLINE\" which are syntactic noise.  Such a macro/extension is complete
> in itself, never having parentheses.  All these names must be syntactically
> valid identifiers.  Alternatively, this variable may be a regular expression
>-which matches the names of such macros.
>+which matches the names of such macros, in which case it must have a submatch
>+1 which matches the actual noise macro name.
>
> If you change this variable's value, call the function
> `c-make-noise-macro-regexps' to set the necessary internal variables (or do
>@@ -1683,7 +1684,8 @@
> which optionally have arguments in parentheses, and which expand to nothing.
> All these names must be syntactically valid identifiers.  These are recognized
> by CC Mode only in declarations.  Alternatively, this variable may be a
>-regular expression which matches the names of such macros.
>+regular expression which matches the names of such macros, in which case it
>+must have a submatch 1 which matches the actual noise macro name.
>
> If you change this variable's value, call the function
> `c-make-noise-macro-regexps' to set the necessary internal variables (or do
>
>
>-- 
>Alan Mackenzie (Nuremberg, Germany).

Message #14 received at 42270 <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 42270 <at> debbugs.gnu.org
Subject: Re: bug#42270: 28.0.50; cc-mode indentation issue with attributes
Date: Mon, 7 Sep 2020 23:55:58 +0200

Hi Alan:

The fix solved the reported problem. If I get any error I will report
ASAP, but for me this solves the issue.

Very thanks
Ergus.

On Sat, Sep 05, 2020 at 12:13:35PM +0000, Alan Mackenzie wrote:
>Hello, Ergus.
>
>Thanks for the bug report.
>
>On Wed, Jul 08, 2020 at 19:03:58 +0200, Ergus wrote:
>> Hi:
>
>> Working in C++ I am getting this indentation difference when arguments
>> has attributes or not:
>
>> TaskDataAccesses(TaskDataAccessesInfo taskAccessInfo)
>> 	: _lock(),
>> 	  _accesses(),
>> 	  _accessFragments(), _taskwaitFragments()
>> {
>> }
>
>
>> TaskDataAccesses(__attribute__((unused)) TaskDataAccessesInfo taskAccessInfo)
>> : _lock(),
>> _accesses(),
>> _accessFragments(), _taskwaitFragments()
>> {
>> }
>
>> The problem seems to be that in the first case the `:` indentation
>> symbol (C-c C-o) is recognised as `member-init-intro` (correct) but in
>> the second one it is detected as a `topmost-intro-cont` which is
>> actually wrong.
>
>Yes, indeed.  There were also problems with the fontification in similar
>fragments, e.g.:
>
>    TaskDataAccesses(foo((unused)) TaskDataAccessesInfo taskAccessInfo)
>    : _lock(),
>        _accesses(),
>        _accessFragments(), _taskwaitFragments()
>    {
>    }
>
>, where typing into "foo" removed the fontification from
>"Task...unused))", which got replaced on the next redisplay (e.g. after
>typing M-x).
>
>I think the patch below fixes all these problems.  Would you please apply
>it, rebuild CC Mode, load it, and try it out on your real source code.  A
>fairly thorough test would be appreciated, here.  Then please let me know
>if the bug is actually fixed, and whether there are any "strange things"
>happening.  Thanks!
>
>> Best,
>> Ergus
>
>> In GNU Emacs 28.0.50 (build 10, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
>>  of 2020-07-07 built on ergus
>> Repository revision: df3ece9d2ed61c9526dbf718e3c96d72bd53dccb
>> Repository branch: master
>> System Description: Debian GNU/Linux 10 (buster)
>
>
>
>diff -r 877c4ad9dae8 cc-engine.el
>--- a/cc-engine.el	Sat Jul 04 16:23:06 2020 +0000
>+++ b/cc-engine.el	Sat Sep 05 11:53:51 2020 +0000
>@@ -2243,7 +2243,7 @@
>
> 	     ((and c-opt-cpp-prefix
> 		   (looking-at c-noise-macro-name-re))
>-	      ;; Skip over a noise macro.
>+	      ;; Skip over a noise macro without parens.
> 	      (goto-char (match-end 1))
> 	      (not (eobp)))
>
>@@ -9141,6 +9141,12 @@
> 				  (catch 'is-function
> 				    (while
> 					(progn
>+					  (while
>+					      (cond
>+					       ((looking-at c-decl-hangon-key)
>+						(c-forward-keyword-clause 1))
>+					       ((looking-at c-noise-macro-with-parens-name-re)
>+						(c-forward-noise-clause))))
> 					  (if (eq (char-after) ?\))
> 					      (throw 'is-function t))
> 					  (setq cdd-got-type (c-forward-type))
>@@ -9789,6 +9795,16 @@
> 				  (save-excursion
> 				    (goto-char after-paren-pos)
> 				    (c-forward-syntactic-ws)
>+				    (progn
>+				      (while
>+					  (cond
>+					   ((and
>+					     c-opt-cpp-prefix
>+					     (looking-at c-noise-macro-with-parens-name-re))
>+					    (c-forward-noise-clause))
>+					   ((looking-at c-decl-hangon-key)
>+					    (c-forward-keyword-clause 1))))
>+				      t)
> 				    (or (c-forward-type)
> 					;; Recognize a top-level typeless
> 					;; function declaration in C.
>diff -r 877c4ad9dae8 cc-mode.el
>--- a/cc-mode.el	Sat Jul 04 16:23:06 2020 +0000
>+++ b/cc-mode.el	Sat Sep 05 11:53:51 2020 +0000
>@@ -2236,7 +2236,8 @@
> (defun c-fl-decl-end (pos)
>   ;; If POS is inside a declarator, return the end of the token that follows
>   ;; the declarator, otherwise return nil.  POS being in a literal does not
>-  ;; count as being in a declarator (on pragmatic grounds).
>+  ;; count as being in a declarator (on pragmatic grounds).  POINT is not
>+  ;; preserved.
>   (goto-char pos)
>   (let ((lit-start (c-literal-start))
> 	enclosing-attribute pos1)
>@@ -2249,12 +2250,31 @@
> 	(let ((lim (save-excursion
> 		     (and (c-beginning-of-macro)
> 			  (progn (c-end-of-macro) (point))))))
>-	  (when (and (c-forward-declarator lim)
>-		     (or (not (eq (char-after) ?\())
>-			 (c-go-list-forward nil lim))
>-		     (eq (c-forward-token-2 1 nil lim) 0))
>-	    (c-backward-syntactic-ws)
>-	    (point)))))))
>+	  (and (c-forward-declarator lim)
>+	       (if (eq (char-after) ?\()
>+		   (and
>+		    (c-go-list-forward nil lim)
>+		    (progn (c-forward-syntactic-ws lim)
>+			   (not (eobp)))
>+		    (progn
>+		      (if (looking-at c-symbol-char-key)
>+			  ;; Deal with baz (foo((bar)) type var), where
>+			  ;; foo((bar)) is not semantically valid.  The result
>+			  ;; must be after var).
>+			  (and
>+			   (goto-char pos)
>+			   (setq pos1 (c-on-identifier))
>+			   (goto-char pos1)
>+			   (progn
>+			     (c-backward-syntactic-ws)
>+			     (eq (char-before) ?\())
>+			   (c-fl-decl-end (1- (point))))
>+			(c-backward-syntactic-ws)
>+			(point))))
>+		 (and (progn (c-forward-syntactic-ws lim)
>+			     (not (eobp)))
>+		      (c-backward-syntactic-ws)
>+		      (point)))))))))
>
> (defun c-change-expand-fl-region (beg end old-len)
>   ;; Expand the region (c-new-BEG c-new-END) to an after-change font-lock
>diff -r 877c4ad9dae8 cc-vars.el
>--- a/cc-vars.el	Sat Jul 04 16:23:06 2020 +0000
>+++ b/cc-vars.el	Sat Sep 05 11:53:51 2020 +0000
>@@ -1668,7 +1668,8 @@
> like \"INLINE\" which are syntactic noise.  Such a macro/extension is complete
> in itself, never having parentheses.  All these names must be syntactically
> valid identifiers.  Alternatively, this variable may be a regular expression
>-which matches the names of such macros.
>+which matches the names of such macros, in which case it must have a submatch
>+1 which matches the actual noise macro name.
>
> If you change this variable's value, call the function
> `c-make-noise-macro-regexps' to set the necessary internal variables (or do
>@@ -1683,7 +1684,8 @@
> which optionally have arguments in parentheses, and which expand to nothing.
> All these names must be syntactically valid identifiers.  These are recognized
> by CC Mode only in declarations.  Alternatively, this variable may be a
>-regular expression which matches the names of such macros.
>+regular expression which matches the names of such macros, in which case it
>+must have a submatch 1 which matches the actual noise macro name.
>
> If you change this variable's value, call the function
> `c-make-noise-macro-regexps' to set the necessary internal variables (or do
>
>
>-- 
>Alan Mackenzie (Nuremberg, Germany).

Message #19 received at 42270-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Ergus <spacibba <at> aol.com>
Cc: acm <at> muc.de, 42270-done <at> debbugs.gnu.org
Subject: Re: bug#42270: 28.0.50; cc-mode indentation issue with attributes
Date: Sat, 12 Sep 2020 16:45:45 +0000

Hello, Ergus.

On Mon, Sep 07, 2020 at 23:55:58 +0200, Ergus wrote:
> Hi Alan:

> The fix solved the reported problem. If I get any error I will report
> ASAP, but for me this solves the issue.

Thanks for the testing!  I've committed the patch to the master branch,
and I'm closing the bug with this post.

> Very thanks
> Ergus.

-- 
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.