From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.cedet,gmane.emacs.devel Subject: Re: ede-linux doesn't work with master emacs repo Date: Tue, 28 Sep 2010 22:39:08 -0400 Message-ID: <4CA2A6CC.70504@siege-engine.com> References: <87aan5tyud.fsf@stupidchicken.com> <4C9E79BA.8080405@siege-engine.com> <87r5ghz9m7.fsf@stupidchicken.com> <4C9EB6CC.6000706@siege-engine.com> <87k4m5su8v.fsf@stupidchicken.com> <4CA262FA.7080906@siege-engine.com> <87ocbhpgzq.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1285727967 6624 80.91.229.12 (29 Sep 2010 02:39:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 29 Sep 2010 02:39:27 +0000 (UTC) Cc: cedet-devel@lists.sourceforge.net, Emacs development discussions To: Chong Yidong Original-X-From: cedet-devel-bounces@lists.sourceforge.net Wed Sep 29 04:39:25 2010 Return-path: Envelope-to: sf-cedet-devel@m.gmane.org Original-Received: from lists.sourceforge.net ([216.34.181.88]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1P0mZk-0008Ns-3s for sf-cedet-devel@m.gmane.org; Wed, 29 Sep 2010 04:39:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=sfs-ml-3.v29.ch3.sourceforge.com) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.69) (envelope-from ) id 1P0mZi-0005UL-MH; Wed, 29 Sep 2010 02:39:18 +0000 Original-Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.69) (envelope-from ) id 1P0mZh-0005UF-EN for cedet-devel@lists.sourceforge.net; Wed, 29 Sep 2010 02:39:17 +0000 X-ACL-Warn: Original-Received: from bird.interbax.net ([75.126.100.114]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) id 1P0mZg-00051X-AN for cedet-devel@lists.sourceforge.net; Wed, 29 Sep 2010 02:39:17 +0000 Original-Received: (qmail 19089 invoked from network); 28 Sep 2010 21:39:10 -0500 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net (HELO ?192.168.1.201?) (71.184.83.10) by interbax.net with SMTP; 28 Sep 2010 21:39:09 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre In-Reply-To: <87ocbhpgzq.fsf@stupidchicken.com> X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1P0mZg-00051X-AN X-BeenThere: cedet-devel@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Development discussions for CEDET projects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: cedet-devel-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.cedet:4651 gmane.emacs.devel:131060 Archived-At: On 09/28/2010 07:48 PM, Chong Yidong wrote: > "Eric M. Ludlam" writes: > >> First, your C file (with Aneesh's example) needs to be parsed correctly. >> >> M-x bovinate RET >> >> will dump out the results. > > Here's what I get: > > (("a" type > (:members > (("k" variable > (:type "int") > (reparse-symbol classsubparts) > #) > ("b" variable > (:type "char") > (reparse-symbol classsubparts) > #)) > :type "struct") > nil #) > ("t" variable > (:type > ("a" type > (:prototype t :type "struct") > nil nil)) > nil #) > ("main" function > (:type "int") > nil #)) > > I notice that the unlink-copy-hook entries are not present. The above > results are identical to the bovinate output for Emacs 23.2 with > built-in CEDET. That's good. The unlink hooks were because I have a decoration mode turned on which you probably don't have. They are also removed during a save. This seems spooky in that it cannot find "struct a" when it is right there in this file. Searches for types, however, generally go through the typecache. Does the typecache (from semanticdb-typecache-dump) show a in the cache? If it is there, then I'm lost here, and debugging the analyzer will need to occur. To do that, you can get the gist of what's going on by using edebug with semantic-analyze-find-tag-sequence-default. It will probably fail in a call to semantic-analyze-type which is a hairy function dealing with inheritance, aliases, typedefs, etc. The last non-doc fix in here was from 2009-04-01. The only other hint was someone discovered a bug where the 'current buffer' would change in the middle of some calls to the parser. If the buffer changes, then this C file would not be current, and would be excluded from type searches. You can test for that while debugging the above. In that case, there were some recent changes I made in the C parser for that, and also in semanticdb-typecache for that. Eric Eric ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev