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 17:49:46 -0400 Message-ID: <4CA262FA.7080906@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> 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 1285710599 13363 80.91.229.12 (28 Sep 2010 21:49:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 28 Sep 2010 21:49:59 +0000 (UTC) Cc: cedet-devel@lists.sourceforge.net, Emacs development discussions To: Chong Yidong Original-X-From: cedet-devel-bounces@lists.sourceforge.net Tue Sep 28 23:49:58 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 1P0i3h-0004m8-Iq for sf-cedet-devel@m.gmane.org; Tue, 28 Sep 2010 23:49:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=sfs-ml-4.v29.ch3.sourceforge.com) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.69) (envelope-from ) id 1P0i3f-0003t3-Q5; Tue, 28 Sep 2010 21:49:55 +0000 Original-Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.69) (envelope-from ) id 1P0i3e-0003st-Ly for cedet-devel@lists.sourceforge.net; Tue, 28 Sep 2010 21:49:54 +0000 X-ACL-Warn: Original-Received: from bird.interbax.net ([75.126.100.114]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) id 1P0i3d-0008AY-FZ for cedet-devel@lists.sourceforge.net; Tue, 28 Sep 2010 21:49:54 +0000 Original-Received: (qmail 18863 invoked from network); 28 Sep 2010 16:49:47 -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 16:49:46 -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: <87k4m5su8v.fsf@stupidchicken.com> X-Spam-Score: 0.1 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.1 AWL AWL: From: address is in the auto white-list X-Headers-End: 1P0i3d-0008AY-FZ 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:4649 gmane.emacs.devel:131057 Archived-At: On 09/28/2010 12:33 PM, Chong Yidong wrote: > "Aneesh Kumar K. V" writes: > >> On Sat, 25 Sep 2010 22:58:20 -0400, "Eric M. Ludlam" wrote: >>> That looks like a problem with the C/C++ parser. It knows that t is >>> a struct, but claims it is a prototype. I think you are missing a >>> change from a short series of checkins ending on 2010-03-14 that deal >>> with the way compound tags (where you have a named struct, AND a >>> declaration of a variable t) are dealt with. >>> >>> I'll take a wild guess that semantic-c.el was not imported right. >>> >>> Eric >> >> Any update here ? Is there a test branch i can test ? > > I'm still trying to figure it out. I did find one set of changes from > semantic-c.el that I had omitted, but after merging it in, and checking > that the relevant files (bovine/c vs semantic-c, bovine/c-by vs > semantic-c-by, and semantic/analyze vs semantic-analyze) have no more > relevant differences, the bug remains. > > Eric, other than semantic-c, is there any other file I should keep an > eye out for? I'm not sure. Let me map out the process, and see what turns up. First, your C file (with Aneesh's example) needs to be parsed correctly. M-x bovinate RET will dump out the results. It should be: -------------- (("a" type (:members (("k" variable (:type "int") (reparse-symbol classsubparts) #) ("b" variable (:type "char") (reparse-symbol classsubparts) #)) :type "struct") (unlink-copy-hook (semantic--tag-unlink-copy-secondary-overlays) link-hook (semantic--tag-link-secondary-overlays) secondary-overlays (#) unlink-hook (semantic--tag-unlink-secondary-overlays)) #) ("t" variable (:type ("a" type (:prototype t :type "struct") nil nil)) (:filename "/tmp/foo.c") #) ("main" function (:type "int") (unlink-copy-hook (semantic--tag-unlink-copy-secondary-overlays) link-hook (semantic--tag-link-secondary-overlays) secondary-overlays (#) unlink-hook (semantic--tag-unlink-secondary-overlays)) #)) --------------- Or something similar. Note that the variable "t" is marked as being of :type "a", so the parser (c.by) and the c support file (semantic-c.el) has converted the single "struct a {} t;" tag into two tags. If it doesn't do this try: C-u M-x bovinate RET M-x bovinate RET to force the buffer to be reparsed, and see if you get a match. If so, you have probably fixed the problem which was due to cached tag info. If this doesn't work, the next thing to check, since your debug output claims it could not find "struct a" is to check the typecache, which is where the types are found. Use: M-x semanticdb-typecache-dump RET Pressing SPC on a line expands it. It should read: --------------- ]# ] Name: "/tmp/foo.c" ] Class: #'semanticdb-typecache ] filestream # * a : struct ] includestream : nil ] stream : nil ] dependants # ------------------ thus exposing "a" in the typecache. If that isn't there, the merge issue may be semanticdb-typecache.el. I see 4 changes that are likely not relevant since this past Feb. A January 2010 change might be relevant. Unfortunately, your debug output said: --------- Current typecache Statistics: 1 types global in this file 0 types from includes. --------- so I'll guess that "a" is in there. At least, something is in there. Since we are all in one file with no external dependencies, none of the "semanticdb-find" related code is going to be involved. There isn't much else to the process that seems relevant to me. 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