From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: CEDET merge question Date: Mon, 14 Sep 2009 14:28:37 -0400 Message-ID: References: <87eiql2w5s.fsf@cyd.mit.edu> <87k50bixsl.fsf@engster.org> <1252759780.4770.76.camel@projectile.siege-engine.com> <1252863531.4770.230.camel@projectile.siege-engine.com> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1252952979 6609 80.91.229.12 (14 Sep 2009 18:29:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Sep 2009 18:29:39 +0000 (UTC) Cc: cyd@stupidchicken.com, raeburn@raeburn.org, deng@randomsample.de, emacs-devel@gnu.org To: eric@siege-engine.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 14 20:29:31 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MnGIq-0005U6-Qi for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2009 20:29:29 +0200 Original-Received: from localhost ([127.0.0.1]:38358 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MnGIq-0007Ru-62 for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2009 14:29:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MnGI8-0006zM-EB for emacs-devel@gnu.org; Mon, 14 Sep 2009 14:28:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MnGI4-0006u9-04 for emacs-devel@gnu.org; Mon, 14 Sep 2009 14:28:43 -0400 Original-Received: from [199.232.76.173] (port=55919 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MnGI3-0006u0-Ig for emacs-devel@gnu.org; Mon, 14 Sep 2009 14:28:39 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:52814) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MnGI3-0003hn-9i for emacs-devel@gnu.org; Mon, 14 Sep 2009 14:28:39 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MnGI1-0000z5-HP; Mon, 14 Sep 2009 14:28:37 -0400 In-reply-to: <1252863531.4770.230.camel@projectile.siege-engine.com> (eric@siege-engine.com) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:115309 Archived-At: Etags, ctags, gnu global, idutils and cscope all have parsers of some sort that parse C and C++ code. Some use regexp matchers. Others have primitive parsers. gcc, of course, has a full language compliant parser which it uses to compile code. I'm not a gcc expert, but I assume that as it parses, it keeps track of the various symbols (functions, variables, namespaces, etc) and where they are. (ie - debug info for gdb). Now I know what you are talking about. This idea seems very appealing, but it has a grave flaw. The flaw comes from the way GCC handles input: it does preprocessing first, and real parsing operates only on the output of preprocessing. So the output that GCC can easily make would describe only the output of preprocessing. Definitions and calls which are not actually compiled won't be seen at all. Macros and references to them won't be seen at all. What etags does now is much better, because it avoids that problem. It is true that output from GCC would give more details about types, etc., and would avoid getting confused in a few strange situations. So there is indeed an advantage to generating the output from GCC. But the disadvantage is much more important. I designed a way to make GCC analyze and report on macros and on the code that's not compiled in. That would get the best of both aspects. But this is not a small job. Please don't ask me to write more details unless you're prepared to do a substantial amount of work and study the GCC parsing code carefully.