bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23313: 25.0.92; CC Mode not recognizing function declarations that r


From: Alan Mackenzie
Subject: bug#23313: 25.0.92; CC Mode not recognizing function declarations that returns pointer to custom type
Date: Sat, 23 Apr 2016 14:58:32 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello again, Mohammed.

On Sat, Apr 23, 2016 at 11:48:30AM -0000, Alan Mackenzie wrote:
> In article <mailman.657.1461074349.7477.bug-gnu-emacs@gnu.org> you wrote:
> > c-mode doesn't recognize (or at least colorize as per current rules)
> > function declarations that returns a pointer (or pointer to pointer) to
> > custom data types:

> > Eg., If my c file contains:

> >      GtkWidget *
> >      my_window_new (GtkApplication *app);

> > Its not recognized as a function declaration, while this works:

> >      GtkWidget
> >      my_window_new (GtkApplication *app);

> Yes.

> I think the reason for this is that the first expression is ambiguous.
> It could be the function declaration you want it to be, or it could be
> the arithmetic expression "GtkWidget times the result of calling
> my_window_new with argument GtkApplication times app".  We need to be
> careful that expressions like that don't get fontified as declarations by
> mistake.

> My current idea for resolving this ambiguity is to examine the token
> before GtkWidget; if this is a ";" or a "}" or a "{", then we have a
> declaration, if it's something else, we have an arithmetic expression.
> Or something like that.

> Give me a little time, and I'll see what I can come up with.

OK, I've written a trial patch along these lines.  Could you try it out,
please, and let me know whether it works OK, or still has some faults.



diff --git a/lisp/progmodes/cc-engine.el b/lisp/progmodes/cc-engine.el
index 62bc236..d72b345 100644
--- a/lisp/progmodes/cc-engine.el
+++ b/lisp/progmodes/cc-engine.el
@@ -7087,6 +7087,9 @@ c-forward-decl-or-cast-1
        backup-if-not-cast
        ;; For casts, the return position.
        cast-end
+       ;; Set when the symbol before `preceding-token-end' is known to
+       ;; terminate the previous construct, or when we're at point-min.
+       at-decl-start
        ;; Have we got a new-style C++11 "auto"?
        new-style-auto
        ;; Save `c-record-type-identifiers' and
@@ -7096,6 +7099,15 @@ c-forward-decl-or-cast-1
        (save-rec-type-ids c-record-type-identifiers)
        (save-rec-ref-ids c-record-ref-identifiers))
 
+    (save-excursion
+      (goto-char preceding-token-end)
+      (setq at-decl-start
+           (or (bobp)
+               (let ((tok-end (point)))
+                 (c-backward-token-2)
+                 (member (buffer-substring-no-properties (point) tok-end)
+                         c-pre-start-tokens)))))
+
     (while (c-forward-annotation)
       (c-forward-syntactic-ws))
 
@@ -7696,12 +7708,15 @@ c-forward-decl-or-cast-1
                          at-type
                          (or at-decl-end (looking-at "=[^=]"))
                          (not context)
-                         (not got-suffix))
-                ;; Got something like "foo * bar;".  Since we're not inside an
-                ;; arglist it would be a meaningless expression because the
-                ;; result isn't used.  We therefore choose to recognize it as
-                ;; a declaration.  Do not allow a suffix since it could then
-                ;; be a function call.
+                         (or (not got-suffix)
+                             at-decl-start))
+                ;; Got something like "foo * bar;".  Since we're not inside
+                ;; an arglist it would be a meaningless expression because
+                ;; the result isn't used.  We therefore choose to recognize
+                ;; it as a declaration.  We only allow a suffix (which makes
+                ;; the construct look like a function call) when
+                ;; `at-decl-start' provides additional evidence that we do
+                ;; have a declaration.
                 (throw 'at-decl-or-cast t))
 
               ;; CASE 17
diff --git a/lisp/progmodes/cc-langs.el b/lisp/progmodes/cc-langs.el
index dd1bccf..c548394 100644
--- a/lisp/progmodes/cc-langs.el
+++ b/lisp/progmodes/cc-langs.el
@@ -1325,6 +1325,14 @@ 'c-opt-op-identitier-prefix
 (c-lang-defconst c-haskell-op-re
   t (c-make-keywords-re nil (c-lang-const c-haskell-op)))
 (c-lang-defvar c-haskell-op-re (c-lang-const c-haskell-op-re))
+
+(c-lang-defconst c-pre-start-tokens
+  "List of operators following which an apparent declaration \(e.g.
+\"t1 *fn (t2 *b);\") is most likely to be an actual declaration
+\(as opposed to an arithmetic expression)."
+  t '(";" "{" "}"))
+(c-lang-defvar c-pre-start-tokens (c-lang-const c-pre-start-tokens))
+
 
 ;;; Syntactic whitespace.
 


> > Package: CC Mode 5.33

> > In GNU Emacs 25.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
> >  of 2016-04-13 built on fedora.localdomain
> > Windowing system distributor 'Fedora Project', version 11.0.11800000
> > Configured features:
> > XPM JPEG TIFF GIF PNG SOUND DBUS GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS
> > LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]