[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [CEDET-devel] ede-linux doesn't work with master emacs repo

From: Eric M. Ludlam
Subject: Re: [CEDET-devel] ede-linux doesn't work with master emacs repo
Date: Tue, 28 Sep 2010 17:49:46 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre

On 09/28/2010 12:33 PM, Chong Yidong wrote:
"Aneesh Kumar K. V"<address@hidden>  writes:

On Sat, 25 Sep 2010 22:58:20 -0400, "Eric M. Ludlam"<address@hidden>  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.


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
   (("k" variable
     (:type "int")
     (reparse-symbol classsubparts)
     #<overlay from 16 to 22 in foo.c>)
    ("b" variable
     (:type "char")
     (reparse-symbol classsubparts)
     #<overlay from 27 to 34 in foo.c>))
   :type "struct")
   (#<overlay from 1 to 12 in foo.c>)
  #<overlay from 1 to 39 in foo.c>)
 ("t" variable
   ("a" type
    (:prototype t :type "struct")
    nil nil))
  (:filename "/tmp/foo.c")
  #<overlay from 1 to 39 in foo.c>)
 ("main" function
  (:type "int")
   (#<overlay from 41 to 48 in foo.c>)
  #<overlay from 41 to 113 in foo.c>))

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:

]#<semanticdb-typecache /tmp/foo.c>
   ] Name: "/tmp/foo.c"
   ] Class: #'semanticdb-typecache
   ] filestream #<TAG LIST: 1 entries>
     * a : struct
   ] includestream : nil
   ] stream : nil
   ] dependants #<list o' stuff: 1 entries>

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]