bug#45160: 27.1; [C] wrong indent for knr-style arguments declaration

bug#45160: 27.1; [C] wrong indent for knr-style arguments declaration

[Bruno]

Within "emacs -Q" session, open the following C source file:

------------------------------ foo.c
int f(i, j, k)
int i;
int j;
int k;
{
return 1;
}

int g(i, j, k)
int i;
int j, k;
{
return 1;
}
------------------------------

Then, do "C-c ." (c-set-style) to "k&r", and "c-c c-o" (c-set-offset),
and set "knr-argdecl-intro" to "+".

We have now the following values in c-offsets-alist :
knr-argdecl-intro : +  (First line of a K&R C argument declaration)
knr-argdecl : 0        (Subsequent lines in a K&R C argument declaration)

re-indent foo.c. At this stage we expect the following indentation for
arguments declarations.

------------------------------ expected indentation
int f(i, j, k)
    int i;
    int j;
    int k;
{
    return 1;
}

int g(i, j, k)
    int i;
    int j, k;
{
    return 1;
}
------------------------------

But we get the following result (please note line 11).

------------------------------ emacs indentation
int f(i, j, k)
    int i;
    int j;
    int k;
{
    return 1;
}

int g(i, j, k)
    int i;
int j, k;
{
    return 1;
}
------------------------------

It should be noted that if we separate each argument on separate lines
(function f), indentation is correct.
It is incorrect if multiple variables are in same declaration (function
g).

Also, multiple variables on first arguments declaration line seems to
have correct indentation.

Regards,

Bruno.

In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32)
 of 2020-10-29 built on lorien
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Ubuntu 20.04.1 LTS

Recent messages:
End of buffer [3 times]
Beginning of buffer [3 times]
Making completion list...
Beginning of buffer [3 times]
previous-line: Beginning of buffer
user-error: No further undo information
C-x C-g is undefined
previous-line: Beginning of buffer [10 times]
scroll-up-command: End of buffer
command-execute: Buffer is read-only: #<buffer *Bug Help*>
Quit
Configured features:
XPM JPEG TIFF GIF PNG SOUND GSETTINGS GLIB NOTIFY INOTIFY LIBSELINUX
GNUTLS FREETYPE HARFBUZZ XFT ZLIB TOOLKIT_SCROLL_BARS GTK2 X11 XDBE XIM
MODULES THREADS PDUMPER GMP

Important settings:
  value of $LC_MESSAGES: C
  value of $LC_MONETARY: en_IE.UTF-8
  value of $LC_NUMERIC: en_IE.UTF-8
  value of $LC_TIME: en_IE.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-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
  blink-cursor-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:
(pp shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search time-date subr-x seq
byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils thingatpt help-fns
radix-tree help-mode cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs cl-loaddefs cl-lib 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 inotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 70553 13929)
 (symbols 48 8643 2)
 (strings 32 22665 2290)
 (string-bytes 1 841592)
 (vectors 16 13093)
 (vector-slots 8 166207 22348)
 (floats 8 23 93)
 (intervals 56 501 6)
 (buffers 1000 17))

bug#45160: 27.1; [C] wrong indent for knr-style arguments declaration

[Alan Mackenzie]

Hello, Bruno.

Thank you indeed for taking the trouble to report this bugi, and thanks
even more for cutting the problem down to a minimal test case.

On Thu, Dec 10, 2020 at 16:02:02 +0100, Bruno wrote:
> Within "emacs -Q" session, open the following C source file:

> ------------------------------ foo.c
> int f(i, j, k)
> int i;
> int j;
> int k;
> {
> return 1;
> }

> int g(i, j, k)
> int i;
> int j, k;
> {
> return 1;
> }
> ------------------------------

> Then, do "C-c ." (c-set-style) to "k&r", and "c-c c-o" (c-set-offset),
> and set "knr-argdecl-intro" to "+".

> We have now the following values in c-offsets-alist :
> knr-argdecl-intro : +  (First line of a K&R C argument declaration)
> knr-argdecl : 0        (Subsequent lines in a K&R C argument declaration)

> re-indent foo.c. At this stage we expect the following indentation for
> arguments declarations.

> ------------------------------ expected indentation
> int f(i, j, k)
>     int i;
>     int j;
>     int k;
> {
>     return 1;
> }

> int g(i, j, k)
>     int i;
>     int j, k;
> {
>     return 1;
> }
> ------------------------------

> But we get the following result (please note line 11).

> ------------------------------ emacs indentation
> int f(i, j, k)
>     int i;
>     int j;
>     int k;
> {
>     return 1;
> }

> int g(i, j, k)
>     int i;
> int j, k;
> {
>     return 1;
> }
> ------------------------------

> It should be noted that if we separate each argument on separate lines
> (function f), indentation is correct.
> It is incorrect if multiple variables are in same declaration (function
> g).

Yes.  Somehow, CC Mode managed not to cater for the occurrence of two or
more identifiers in the same declaration.

> Also, multiple variables on first arguments declaration line seems to
> have correct indentation.

Indeed.

The following patch should fix the problem.  Would you please apply it
to your Emacs (cc-engine.el is in .../emacs/lisp/progmodes) and byte
compile cc-engine.el.  Then please try it out on your real source code,
and either confirm the bug has indeed been fixed, or say what's still
wrong.  (If you would like any help with the patching or byte compiling,
feel free to send me private email.)



diff -r 863d08a1858a cc-engine.el
--- a/cc-engine.el	Thu Nov 26 11:27:52 2020 +0000
+++ b/cc-engine.el	Fri Dec 11 15:57:08 2020 +0000
@@ -10849,11 +10849,11 @@
 	     (low-lim (max (or lim (point-min))   (or macro-start (point-min))))
 	     before-lparen after-rparen
 	     (here (point))
-	     (pp-count-out 20)	; Max number of paren/brace constructs before
-				; we give up.
+	     (pp-count-out 20)	 ; Max number of paren/brace constructs before
+					; we give up
 	     ids	      ; List of identifiers in the parenthesized list.
 	     id-start after-prec-token decl-or-cast decl-res
-	     c-last-identifier-range identifier-ok)
+	     c-last-identifier-range semi-position+1)
 	(narrow-to-region low-lim (or macro-end (point-max)))
 
 	;; Search backwards for the defun's argument list.  We give up if we
@@ -10887,8 +10887,8 @@
 		   (setq after-rparen (point)))
 		  ((eq (char-before) ?\])
 		   (setq after-rparen nil))
-		  (t ; either } (hit previous defun) or = or no more
-		     ; parens/brackets.
+		  (t	       ; either } (hit previous defun) or = or no more
+					; parens/brackets.
 		   (throw 'knr nil)))
 
 	    (if after-rparen
@@ -10945,31 +10945,35 @@
 		       (forward-char)	; over the )
 		       (setq after-prec-token after-rparen)
 		       (c-forward-syntactic-ws)
+		       ;; Each time around the following checks one
+		       ;; declaration (which may contain several identifiers).
 		       (while (and
-			       (or (consp (setq decl-or-cast
-						(c-forward-decl-or-cast-1
-						 after-prec-token
-						 nil ; Or 'arglist ???
-						 nil)))
-				   (progn
-				     (goto-char after-prec-token)
-				     (c-forward-syntactic-ws)
-				     (setq identifier-ok (eq (char-after) ?{))
-				     nil))
-			       (eq (char-after) ?\;)
-			       (setq after-prec-token (1+ (point)))
+			       (consp (setq decl-or-cast
+					    (c-forward-decl-or-cast-1
+					     after-prec-token
+					     nil ; Or 'arglist ???
+					     nil)))
+			       (memq (char-after) '(?\; ?\,))
 			       (goto-char (car decl-or-cast))
-			       (setq decl-res (c-forward-declarator))
-			       (setq identifier-ok
-				     (member (buffer-substring-no-properties
-					(car decl-res) (cadr decl-res))
-				       ids))
-			       (progn
-				 (goto-char after-prec-token)
-				 (prog1 (< (point) here)
-				   (c-forward-syntactic-ws))))
-			 (setq identifier-ok nil))
-		       identifier-ok))
+			       (save-excursion
+				 (setq semi-position+1
+				       (c-syntactic-re-search-forward
+					";" (+ (point) 1000) t)))
+			       (c-do-declarators
+				semi-position+1 t nil nil
+				(lambda (id-start id-end _next _not-top
+						  _func _init)
+				  (if (not (member
+					    (buffer-substring-no-properties
+					     id-start id-end)
+					    ids))
+				      (throw 'knr nil))))
+
+			       (progn (forward-char)
+				      (<= (point) here))
+			       (progn (c-forward-syntactic-ws)
+				      t)))
+		       t))
 		    ;; ...Yes.  We've identified the function's argument list.
 		    (throw 'knr
 			   (progn (goto-char after-rparen)



> Regards,

> Bruno.

> In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32)
>  of 2020-10-29 built on lorien
> Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
> System Description: Ubuntu 20.04.1 LTS

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#45160: 27.1; [C] wrong indent for knr-style arguments declaration

[Bruno Raoult]

Thanks Alan,

On Fri, 11 Dec 2020 at 17:33, Alan Mackenzie <acm@muc.de> wrote:
> > It should be noted that if we separate each argument on separate lines
> > (function f), indentation is correct.
> > It is incorrect if multiple variables are in same declaration (function
> > g).
>
> Yes.  Somehow, CC Mode managed not to cater for the occurrence of two or
> more identifiers in the same declaration.
>
> > Also, multiple variables on first arguments declaration line seems to
> > have correct indentation.
>
> Indeed.
>
> The following patch should fix the problem.  Would you please apply it
> to your Emacs (cc-engine.el is in .../emacs/lisp/progmodes) and byte
> compile cc-engine.el.  Then please try it out on your real source code,
> and either confirm the bug has indeed been fixed, or say what's still
> wrong.  (If you would like any help with the patching or byte compiling,
> feel free to send me private email.)

That fix was really fast !

I applied the patch, and it appears to work in a few source files I did try.
I did not notice any side effect so far : I will keep your version,
and let you know (in this bug thread) if I notice any issue that is
not present in original version.

Thanks again,

Bruno.

-- 
2 + 2 = 5, for very large values of 2.

bug#45160: 27.1; [C] wrong indent for knr-style arguments declaration

[Alan Mackenzie]

Hello again, Bruno.

On Fri, Dec 11, 2020 at 20:22:19 +0100, Bruno Raoult wrote:
> Thanks Alan,

[ .... ]

> > The following patch should fix the problem.  Would you please apply
> > it to your Emacs (cc-engine.el is in .../emacs/lisp/progmodes) and
> > byte compile cc-engine.el.  Then please try it out on your real
> > source code, and either confirm the bug has indeed been fixed, or say
> > what's still wrong.  (If you would like any help with the patching or
> > byte compiling, feel free to send me private email.)

> That fix was really fast !

It was a high quality bug report, and easy to diagnose.

> I applied the patch, and it appears to work in a few source files I did
> try.  I did not notice any side effect so far : I will keep your
> version, and let you know (in this bug thread) if I notice any issue
> that is not present in original version.

Thank you for such a fast test.  I am closing the bug with this post.

> Thanks again,

> Bruno.

> -- 
> 2 + 2 = 5, for very large values of 2.

-- 
Alan Mackenzie (Nuremberg, Germany).