On 09/28/2010 12:33 PM, Chong Yidong wrote:
> "Aneesh Kumar K. V"<aneesh.kumar@...> writes:
>
>> On Sat, 25 Sep 2010 22:58:20 -0400, "Eric M. Ludlam"<eric@...> 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)
#<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")
(unlink-copy-hook
(semantic--tag-unlink-copy-secondary-overlays)
link-hook
(semantic--tag-link-secondary-overlays)
secondary-overlays
(#<overlay from 1 to 12 in foo.c>)
unlink-hook
(semantic--tag-unlink-secondary-overlays))
#<overlay from 1 to 39 in foo.c>)
("t" variable
(:type
("a" type
(:prototype t :type "struct")
nil nil))
(:filename "/tmp/foo.c")
#<overlay from 1 to 39 in foo.c>)
("main" function
(:type "int")
(unlink-copy-hook
(semantic--tag-unlink-copy-secondary-overlays)
link-hook
(semantic--tag-link-secondary-overlays)
secondary-overlays
(#<overlay from 41 to 48 in foo.c>)
unlink-hook
(semantic--tag-unlink-secondary-overlays))
#<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.
Eric
|