[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).
- bug#23313: 25.0.92; CC Mode not recognizing function declarations that returns pointer to custom type, Mohammed Sadik, 2016/04/19
- Message not available
- bug#23313: 25.0.92; CC Mode not recognizing function declarations that returns pointer to custom type, Alan Mackenzie, 2016/04/23
- bug#23313: 25.0.92; CC Mode not recognizing function declarations that returns pointer to custom type,
Alan Mackenzie <=
- bug#23313: 25.0.92; CC Mode not recognizing function declarations that returns pointer to custom type, Mohammed Sadik, 2016/04/23
- bug#23313: 25.0.92; CC Mode not recognizing function declarations that returns pointer to custom type, Alan Mackenzie, 2016/04/25
- bug#23313: 25.0.92; CC Mode not recognizing function declarations that returns pointer to custom type, Mohammed Sadik, 2016/04/25
- bug#23313: 25.0.92; CC Mode not recognizing function declarations that returns pointer to custom type, Alan Mackenzie, 2016/04/25
- bug#23313: 25.0.92; CC Mode not recognizing function declarations that returns pointer to custom type, Mohammed Sadik, 2016/04/25
Message not available