From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Help etags parse lisp.j Date: Mon, 21 Mar 2016 18:10:41 +0200 Message-ID: <83y49b6cce.fsf@gnu.org> References: <83fuvl6p97.fsf@gnu.org> <87k2kxuk8i.fsf@linux-m68k.org> <83a8lt6nen.fsf@gnu.org> <56EFA8B2.90904@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1458576689 30379 80.91.229.3 (21 Mar 2016 16:11:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Mar 2016 16:11:29 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Andreas Schwab Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 21 17:11:29 2016 Return-path: Envelope-to: ged-emacs-devel@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 1ai2QJ-0005dq-Qc for ged-emacs-devel@m.gmane.org; Mon, 21 Mar 2016 17:11:19 +0100 Original-Received: from localhost ([::1]:58785 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ai2QI-0007PT-TI for ged-emacs-devel@m.gmane.org; Mon, 21 Mar 2016 12:11:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ai2Q9-0007JM-Tz for emacs-devel@gnu.org; Mon, 21 Mar 2016 12:11:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ai2Q4-00050W-0s for emacs-devel@gnu.org; Mon, 21 Mar 2016 12:11:09 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58567) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ai2Q3-00050S-U1; Mon, 21 Mar 2016 12:11:03 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2822 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ai2Q3-0004AD-2B; Mon, 21 Mar 2016 12:11:03 -0400 In-reply-to: (message from Andreas Schwab on Mon, 21 Mar 2016 11:58:14 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:202006 Archived-At: > From: Andreas Schwab > Cc: Eli Zaretskii , emacs-devel@gnu.org > Date: Mon, 21 Mar 2016 11:58:14 +0100 > > Paul Eggert writes: > > > Eli Zaretskii wrote: > >>> >Can't etags reset its parser state after a toplevel semicolon? > >> No, evidently because it wants to support K&R function definition: > >> > >> void foo () int arg; { bar = arg; } > > > > OK, how about if it resets its state when it sees a toplevel semicolon not > > immediately followed by "{"? > > void foo (a, b) int a; int b; {} Right. To expand on that, a K&R function definition generally looks like this: TYPE0 foo (arg1, arg2, arg3, ..., argN) TYPE1 arg1; TYPE2 arg2; TYPE3 arg3; ... TYPEN argN; { body... } Compare this with what we have in lisp.h: extern Lisp_Object make_formatted_string (char *, const char *, ...) ATTRIBUTE_FORMAT_PRINTF (2, 3); extern Lisp_Object make_unibyte_string (const char *, ptrdiff_t); SOMETHING; SOMETHING-ELSE; ... INLINE Lisp_Object build_unibyte_string (const char *str) { return make_unibyte_string (str, strlen (str)); } A tool that doesn't really parse C will have hard time discerning between these two. In particular, by the time etags finds a top-level semicolon not followed by a "{", it's too late, because the first inline function (in this case, build_unibyte_string) was already missed. Hmm... can we use the fact that in a K&R definition, the last token before the opening brace "{" of the body is always a semicolon? So if there's no semi-colon there, then it's a function that needs to be tagged? (Of course, the semicolon could be hidden behind some clever macro, but I think we don't need to cater to such uses.)