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: Sun, 20 Mar 2016 19:59:28 +0200 Message-ID: <83a8lt6nen.fsf@gnu.org> References: <83fuvl6p97.fsf@gnu.org> <87k2kxuk8i.fsf@linux-m68k.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1458496814 5472 80.91.229.3 (20 Mar 2016 18:00:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Mar 2016 18:00:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: Andreas Schwab Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 20 19:00:03 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 1ahhdz-0004pE-Ay for ged-emacs-devel@m.gmane.org; Sun, 20 Mar 2016 19:00:03 +0100 Original-Received: from localhost ([::1]:53898 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahhdy-0003vh-LO for ged-emacs-devel@m.gmane.org; Sun, 20 Mar 2016 14:00:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59024) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahhdu-0003ub-5L for emacs-devel@gnu.org; Sun, 20 Mar 2016 13:59:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ahhdq-0006PQ-Vl for emacs-devel@gnu.org; Sun, 20 Mar 2016 13:59:58 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33575) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahhdq-0006PM-SU; Sun, 20 Mar 2016 13:59:54 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1446 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ahhdq-0006AZ-39; Sun, 20 Mar 2016 13:59:54 -0400 In-reply-to: <87k2kxuk8i.fsf@linux-m68k.org> (message from Andreas Schwab on Sun, 20 Mar 2016 18:34:05 +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:201951 Archived-At: > From: Andreas Schwab > Cc: emacs-devel@gnu.org > Date: Sun, 20 Mar 2016 18:34:05 +0100 > > > extern _Noreturn void emacs_abort (void) NO_INLINE; > > > > Specifically, the very next inline function doesn't wind up in TAGS. > > The problem is that NO_INLINE part after the argument list. These > > macros expand either to __attribute__((SOMETHING)) or to nothing; > > etags knows about __attribute__, but it cannot know about the macros > > we use for that. The problem happens with any attribute we hide > > behind a macro, not just with NO_INLINE. > > 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; } That's why, whenever it finds lines like the one above, it resets its state only after the closing brace. Hmm... can a function definition use mixed K&R and ANSI style, i.e. some arguments declared inside the parentheses and some outside, like this: void foo (int arg1) int arg2; { bar = baz; } Or is this invalid C? If so, perhaps we could take note of nonempty argument list.