From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#23313: 25.0.92; CC Mode not recognizing function declarations that returns pointer to custom type Date: Mon, 25 Apr 2016 11:14:34 +0000 Message-ID: <20160425111434.GA4020@acm.fritz.box> References: <20160423114830.99485.qmail@mail.muc.de> <20160423145831.GA4624@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1461583165 16032 80.91.229.3 (25 Apr 2016 11:19:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Apr 2016 11:19:25 +0000 (UTC) Cc: 23313@debbugs.gnu.org To: Mohammed Sadik Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 25 13:19:14 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aueXq-0001x7-7l for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Apr 2016 13:19:14 +0200 Original-Received: from localhost ([::1]:59429 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aueXl-0003BK-UD for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Apr 2016 07:19:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aueXi-00039F-Df for bug-gnu-emacs@gnu.org; Mon, 25 Apr 2016 07:19:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aueXh-0007fi-Eo for bug-gnu-emacs@gnu.org; Mon, 25 Apr 2016 07:19:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aueXe-0007fK-43; Mon, 25 Apr 2016 07:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1aueXe-0004OB-0D; Mon, 25 Apr 2016 07:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Mon, 25 Apr 2016 11:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23313 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 23313-submit@debbugs.gnu.org id=B23313.146158309616820 (code B ref 23313); Mon, 25 Apr 2016 11:19:01 +0000 Original-Received: (at 23313) by debbugs.gnu.org; 25 Apr 2016 11:18:16 +0000 Original-Received: from localhost ([127.0.0.1]:45698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aueWu-0004NE-50 for submit@debbugs.gnu.org; Mon, 25 Apr 2016 07:18:16 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:30099) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aueWr-0004N5-OC for 23313@debbugs.gnu.org; Mon, 25 Apr 2016 07:18:14 -0400 Original-Received: (qmail 10044 invoked by uid 3782); 25 Apr 2016 11:18:12 -0000 Original-Received: from acm.muc.de (p548A5E62.dip0.t-ipconnect.de [84.138.94.98]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 25 Apr 2016 13:18:11 +0200 Original-Received: (qmail 4160 invoked by uid 1000); 25 Apr 2016 11:14:34 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:116813 Archived-At: Hello, Mohammed. On Sat, Apr 23, 2016 at 10:17:13PM +0530, Mohammed Sadik wrote: > On 4/23/16, Alan Mackenzie wrote: > > 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. > > The patch was not applying to my Emacs 25.0.93 source. patched by hand. > And I tried your patch. It was working right, with some minor glitches: Sorry about the bad patch. I made it to apply to the emacs-25 branch. Obviously, I made a mistake somewhere. > * The right face is applied only after the statement is made complete > with a ';' > GtkWidget > my_app_window (|) > The above code is interpreted as a function (without ';') but the one > below doesn't: > GtkWidget * > my_app_window (|) > There might be issues guessing the right way. That is, if the * is for > representing a > pointer or mathematical multiplication, .... That's precisely the issue. I've tried removing the condition for the semicolon. Unfortunately, CC Mode then misfontifies both of the following (from a CC Mode test file) as declarations: t3 *id (NULL) + 1; t3 (id) (NULL) + 1; > .... but the following is also not interpreted right (when without > ';'): > GtkWidget ** > my_app_window (|) > As ** is clearly a pointer to pointer, cc-mode shall be able to guess > very early. It's not actually that clear. The second star could be accessing the pointer returned by calling my_app_window. ;-) > I'm not an expert, though the following interpretation might be good: > 1. GtkWidget | > 'GtkWidget' may be an identifier, data type, etc. > 2. GtkWidget *| > 'GtkWidget' _may_ be a data type (as '*' _may_ not be present to represent > multiplication as its is not allowed as lvalue). > 3. GtkWidget **| > 'GtkWidget' is surely a data type. (not implemented now in c-mode) See above. > 4. GtkWidget * my_app_window| > (2) and my_app_window may be an identifier. > 5. GtkWidget * my_app_window (| > 'GtkWidget' may be a data type and 'my_app_window' may be a function. > 6. GtkWidget * my_app_window (int| > This is not a function call, as 'int' is a data type. So probably > a function definition/declaration). I'd agree with you on number 6. Trouble is, most types used are user defined, and not easy to distinguish from variable names. I've thought long and hard about this needing a semicolon to fontify an "ambiguous" declaration. In the end, I've decided that this is a lesser evil than leaving valid (if unusual and not very useful) function invocations wrongly fontified as declarations. There is also something positive in reminding the user to type that final semicolon, even if it's not consistent. So, sorry about this. So I think this bug is now fixed. Assuming I don't hear from you about any more problems, I'll commit the patch to the master branch, and mark the bug report as fixed. Thanks for all the trouble you've taken over it. > Regards > Mohammed Sadik -- Alan Mackenzie (Nuremberg, Germany).