bug#35768: 27.0.50; CC-Mode problems with function definitions with macro names

bug#35768: 27.0.50; CC-Mode problems with function definitions with macro names

[Mauro Aranda]

[-- Attachment #1: Type: text/plain, Size: 4090 bytes --]

Hello.

I noticed CC-Mode sometimes doesn't identify correctly function names
when a macro name is involved in the function definition.  Try the
following recipe to see the problem:

1) emacs -Q
2) C-x C-f test.c
3) Type the following function definitions:

int DUMMY
foo (void)
{
  return 1;
}

DUMMY int
bar (void)
{
  return 0;
}

4) Observe that:
a) foo doesn't get fontified with font-lock-function-name-face, but
DUMMY does.  Consequently, C-c C-z inside foo echoes
DUMMY as the function name, in the echo area.
b) In bar, DUMMY gets font-lock-type-face, which I don't
think is correct.  bar gets font-lock-function-name-face and C-c C-z
works as expected.

---

Other problem is with fontification of the return type in the following:

bool DUMMY
baz_t (void)
{
  return true;
}

bool
baz_f (void)
{
  return false;
}

Observe that bool doesn't get fontified in baz_t, but DUMMY does.  When
DUMMY is not present, bool gets fontified correctly (as in baz_f).


If it helps, I found the problem in a source file with functions that
have macros that declare some function attributes, like
_GL_ATTRIBUTE_PURE.

Best regards,
Mauro.



In GNU Emacs 27.0.50 (build 5, i686-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2019-05-15 built on the-blackbeard
Repository revision: 50b1ce0185cd7b5f8be124eb4a612fd56e4e0657
Repository branch: revert-buffer-with-fine-grain
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Ubuntu 16.04.6 LTS

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

Configured using:
 'configure CFLAGS=-O3'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: en_US.utf8
  value of $XMODIFIERS:
  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
  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:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
easymenu mml-sec password-cache epa derived epg epg-config gnus-util
rmail rmail-loaddefs text-property-search time-date 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
elec-pair mule-util 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 menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame 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 minibuffer
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 lcms2 dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 8 43995 8711)
 (symbols 24 5878 1)
 (strings 16 14997 2517)
 (string-bytes 1 501374)
 (vectors 8 8875)
 (vector-slots 4 114380 10618)
 (floats 8 18 13)
 (intervals 28 194 0)
 (buffers 564 11)
 (heap 1024 7599 790))

[-- Attachment #2: Type: text/html, Size: 4626 bytes --]

bug#35768: 27.0.50; CC-Mode problems with function definitions with macro names

[Noam Postavsky]

Mauro Aranda <maurooaranda@gmail.com> writes:

> I noticed CC-Mode sometimes doesn't identify correctly function names
> when a macro name is involved in the function definition.  Try the
> following recipe to see the problem:
>
> 1) emacs -Q
> 2) C-x C-f test.c
> 3) Type the following function definitions:
>
> int DUMMY
> foo (void)
> {
>   return 1;
> }
>
> DUMMY int
> bar (void)
> {
>   return 0;
> }
>
> 4) Observe that:
> a) foo doesn't get fontified with font-lock-function-name-face, but
> DUMMY does.  Consequently, C-c C-z inside foo echoes
> DUMMY as the function name, in the echo area.
> b) In bar, DUMMY gets font-lock-type-face, which I don't
> think is correct.  bar gets font-lock-function-name-face and C-c C-z
> works as expected.
>
> ---
>
> Other problem is with fontification of the return type in the following:
>
> bool DUMMY
> baz_t (void)
> {
>   return true;
> }
>
> bool
> baz_f (void)
> {
>   return false;
> }
>
> Observe that bool doesn't get fontified in baz_t, but DUMMY does.  When
> DUMMY is not present, bool gets fontified correctly (as in baz_f).
>
>
> If it helps, I found the problem in a source file with functions that
> have macros that declare some function attributes, like
> _GL_ATTRIBUTE_PURE.

Have you tried customizing c-noise-macro-names, as described in (ccmode) Noise Macros?

bug#35768: 27.0.50; CC-Mode problems with function definitions with macro names

[Mauro Aranda]

[-- Attachment #1: Type: text/plain, Size: 1593 bytes --]

> Have you tried customizing c-noise-macro-names, as described in (ccmode)
Noise Macros?

Hello Noam, thanks for your answer.

I didn't know of c-noise-macro-names, thanks.  If after step 1) I eval
the following:
(defun my-c-mode-hook ()
  (setq c-noise-macro-names (append c-noise-macro-names '("DUMMY")))
  (c-make-noise-macro-regexps))
(add-hook 'c-mode-hook 'my-c-mode-hook)

And then follow the steps of my recipe, CC Mode works correctly.


However, the following recipe exposes another problem, I think:
1) emacs -Q
2) Eval the following:
(defun my-c-mode-hook ()
  (setq c-noise-macro-with-parens-names (append
c-noise-macro-with-parens-names
                                                '("DUMMY_1" "DUMMY_2")))
  (c-make-noise-macro-regexps))
(add-hook 'c-mode-hook 'my-c-mode-hook)

3) C-x C-f test.c
4) Type the following (no need to type the #define lines, that's just for
completion)
#define DUMMY_1(params)
#define DUMMY_2(params)

int DUMMY_1 (1) DUMMY_2 (2)
foo (void)
{
  return 0;
}

5) Observe that DUMMY_1 (1) is ignored as expected, but DUMMY_2 gets
font-lock-type-face.  I think that's not right.

6) To be sure that I customized c-noise-macro-with-parens-names correctly, I
tried a regexp search with c-noise-macro-with-parens-name-re, from the
beginning of the buffer:
(re-search-forward c-noise-macro-with-parens-name-re)
That gets four hits, as it should (2 for DUMMY_1 and 2 for DUMMY_2), meaning
that it does find DUMMY_2 as a noise macro with parens.

Is that a bug? Or is there something else I can use to help CC Mode not get
confused?

Best regards,
Mauro.

[-- Attachment #2: Type: text/html, Size: 1904 bytes --]

bug#35768: 27.0.50; CC-Mode problems with function definitions with macro names

[Alan Mackenzie]

Hello, Mauro.

On Fri, May 17, 2019 at 09:40:09 -0300, Mauro Aranda wrote:

[ .... ]

> However, the following recipe exposes another problem, I think:
> 1) emacs -Q
> 2) Eval the following:
> (defun my-c-mode-hook ()
>   (setq c-noise-macro-with-parens-names (append
> c-noise-macro-with-parens-names
>                                                 '("DUMMY_1" "DUMMY_2")))
>   (c-make-noise-macro-regexps))
> (add-hook 'c-mode-hook 'my-c-mode-hook)

> 3) C-x C-f test.c
> 4) Type the following (no need to type the #define lines, that's just for
> completion)
> #define DUMMY_1(params)
> #define DUMMY_2(params)

> int DUMMY_1 (1) DUMMY_2 (2)
> foo (void)
> {
>   return 0;
> }

> 5) Observe that DUMMY_1 (1) is ignored as expected, but DUMMY_2 gets
> font-lock-type-face.  I think that's not right.

It's not right, no.

> 6) To be sure that I customized c-noise-macro-with-parens-names correctly, I
> tried a regexp search with c-noise-macro-with-parens-name-re, from the
> beginning of the buffer:
> (re-search-forward c-noise-macro-with-parens-name-re)
> That gets four hits, as it should (2 for DUMMY_1 and 2 for DUMMY_2), meaning
> that it does find DUMMY_2 as a noise macro with parens.

Just as a matter of interest, I also tried putting "DUMMY_3" into
c-noise-macro-names, and inserting it in the middle of the pertinent
line in your test file.

> Is that a bug? Or is there something else I can use to help CC Mode not get
> confused?

It's a bug.  I hope the following patch fixes it.  Would you please
apply this patch, try it out in your real code, and confirm it fixes the
bug, or tell me what's still not working.  Thanks!



diff -r 43b8aba74b73 cc-engine.el
--- a/cc-engine.el	Wed May 15 08:45:55 2019 +0000
+++ b/cc-engine.el	Sat May 18 12:45:53 2019 +0000
@@ -4500,6 +4500,30 @@
 		       (goto-char pos))))))
       (< (point) start)))
 
+(defun c-end-of-token (&optional back-limit)
+  ;; Move to the end of the token we're just before or in the middle of.
+  ;; BACK-LIMIT may be used to bound the backward search; if given it's
+  ;; assumed to be at the boundary between two tokens.  Return non-nil if the
+  ;; point is moved, nil otherwise.
+  ;;
+  ;; This function might do hidden buffer changes.
+  (let ((start (point)))
+    (cond ;; ((< (skip-syntax-backward "w_" (1- start)) 0)
+     ;;  (skip-syntax-forward "w_"))
+     ((> (skip-syntax-forward "w_") 0))
+     ((< (skip-syntax-backward ".()" back-limit) 0)
+      (while (< (point) start)
+	(if (looking-at c-nonsymbol-token-regexp)
+	    (goto-char (match-end 0))
+	  ;; `c-nonsymbol-token-regexp' should always match since
+	  ;; we've skipped backward over punctuation or paren
+	  ;; syntax, but move forward in case it doesn't so that
+	  ;; we don't leave point earlier than we started with.
+	  (forward-char))))
+     (t (if (looking-at c-nonsymbol-token-regexp)
+	    (goto-char (match-end 0)))))
+    (> (point) start)))
+
 (defun c-end-of-current-token (&optional back-limit)
   ;; Move to the end of the current token.  Do not move if not in the
   ;; middle of one.  BACK-LIMIT may be used to bound the backward
@@ -5885,9 +5909,14 @@
 	     ;; comment style has removed face properties from a construct,
 	     ;; and is relying on `c-font-lock-declarations' to add them
 	     ;; again.
-	     (and (< (point) cfd-limit)
-		  (looking-at c-doc-line-join-re)
-		  (goto-char (match-end 0)))))
+	     (cond
+	      ((looking-at c-noise-macro-name-re)
+	       (c-forward-noise-clause-not-macro-decl nil)) ; Returns t.
+	      ((looking-at c-noise-macro-with-parens-name-re)
+	       (c-forward-noise-clause-not-macro-decl t)) ; Always returns t.
+	      ((and (< (point) cfd-limit)
+		    (looking-at c-doc-line-join-re))
+	       (goto-char (match-end 0))))))
        ;; Set the position to continue at.  We can avoid going over
        ;; the comments skipped above a second time, but it's possible
        ;; that the comment skipping has taken us past `cfd-prop-match'
@@ -5916,6 +5945,8 @@
   ;; o	The first token after the end of submatch 1 in
   ;;	`c-decl-prefix-or-start-re' when that submatch matches.	 This
   ;;	submatch is typically a (L or R) brace or paren, a ;, or a ,.
+  ;;    As a special case, noise macros are skipped over and the next
+  ;;    token regarded as the spot.
   ;; o	The start of each `c-decl-prefix-or-start-re' match when
   ;;	submatch 1 doesn't match.  This is, for example, the keyword
   ;;	"class" in Pike.
@@ -7452,6 +7483,21 @@
       (c-forward-syntactic-ws))
   t)
 
+(defun c-forward-noise-clause-not-macro-decl (maybe-parens)
+  ;; Point is at a noise macro identifier, which, when MAYBE-PARENS is
+  ;; non-nil, optionally takes paren arguments.  Go forward over this name,
+  ;; and when there may be optional parens, any parenthesis expression which
+  ;; follows it, but DO NOT go over any macro declaration which may come
+  ;; between them.  Always return t.
+  (c-end-of-token)
+  (when maybe-parens
+    (let ((here (point)))
+      (c-forward-comments)
+      (if (not (and (eq (char-after) ?\()
+		    (c-go-list-forward)))
+	  (goto-char here))))
+  t)
+
 (defun c-forward-keyword-clause (match)
   ;; Submatch MATCH in the current match data is assumed to surround a
   ;; token.  If it's a keyword, move over it and any immediately
@@ -9060,7 +9106,10 @@
 	   ((and c-opt-cpp-prefix
 		 (looking-at c-noise-macro-with-parens-name-re))
 	    (setq noise-start (point))
-	    (c-forward-noise-clause)
+	    (while
+		(and
+		  (c-forward-noise-clause)
+		  (looking-at c-noise-macro-with-parens-name-re)))
 	    (setq kwd-clause-end (point))))
 
 	  (when (setq found-type (c-forward-type t)) ; brace-block-too


> Best regards,
> Mauro.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#35768: 27.0.50; CC-Mode problems with function definitions with macro names

[Mauro Aranda]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Mauro.

>> Is that a bug? Or is there something else I can use to help CC Mode not
get
>> confused?
>
> It's a bug.  I hope the following patch fixes it.  Would you please
> apply this patch, try it out in your real code, and confirm it fixes the
> bug, or tell me what's still not working.  Thanks!

Hello Alan.

The patch works like a charm.  Thank you!

[-- Attachment #2: Type: text/html, Size: 590 bytes --]

bug#35768: 27.0.50; CC-Mode problems with function definitions with macro names

[Alan Mackenzie]

Hello again, Mauro.

On Sat, May 18, 2019 at 10:56:35 -0300, Mauro Aranda wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Hello, Mauro.

> >> Is that a bug? Or is there something else I can use to help CC Mode not
> >> get confused?

> > It's a bug.  I hope the following patch fixes it.  Would you please
> > apply this patch, try it out in your real code, and confirm it fixes
> > the bug, or tell me what's still not working.  Thanks!

> Hello Alan.

> The patch works like a charm.  Thank you!

Thank you.  I've committed the patch, and I'm now closing the bug.

-- 
Alan Mackenzie (Nuremberg, Germany).