Thanks for the patch. That is a good call on identifying the problem w/
eq. Usually, all the types are compressed into the semantic typecache,
and dups are removed. That means analysis has a smaller sorted body to
search, speeding things up. It also implies that eq should be ok.
Apparently not the case though. :)
I tried out your patch, and used `semantic-tag-similar-p' so that tags
that are basically the same, but show up in different places (ie - file
location, faux tags vs real tags, etc) will still be considered equal.
It appears to pass all the regular unit tests.
Could someone give it a try to make sure it is sufficient for this problem?
On 12/17/2012 02:12 PM, Tomasz Gajewski wrote:
> Manuel Schneckenreither<manuel.schnecki@...> writes:
>> I was using the semantic-speedbar-analysis for my project written in C
>> when emacs got completely stuck and I had to wait for about 30-40
>> seconds until the speedbar was loaded. During that process it says:
>> "Possible recursion for '_IO_FILE_plus'". I do not have any struct or
>> typedef called like this in my project, therefore I checked the
>> includes directory and figered out that there is the problem:
>> Semantic includes the /usr/include folder for my installed
>> libraries. So if I grep for 'IO_FILE_PLUS in there I get following
>> $ grep IO_FILE_plus *
>> libio.h:struct _IO_FILE_plus;
>> libio.h:extern struct _IO_FILE_plus _IO_2_1_stdin_;
>> libio.h:extern struct _IO_FILE_plus _IO_2_1_stdout_;
>> libio.h:extern struct _IO_FILE_plus _IO_2_1_stderr_;
>> I mean I can't really delete that library and couldn't find any help
>> using google etc.
>> Could someone please give me a hint on that?
> If your error message is "Possible metatype recursion for _IO_FILE_plus"
> then following patch might help. I experienced this problem during name
> completion after problems with parsing Qt classes where forward
> declaration was discovered as class declaration.
> I would like someone to comment on this patch if it is correct and if it
> doesn't make this code run much slower. I don't really know what those
> expressions mean but during debugging they seemed to be the same but
> 'eq' didn't know about it. So IMHO either this patch is ok or parsing
> part should be fixed to produce exactly the same object for both
> expressions in 'eq'.
> === modified file 'lisp/cedet/semantic/analyze/fcn.el'
> --- a/lisp/cedet/semantic/analyze/fcn.el 2012-12-05 18:52:09 +0000
> +++ b/lisp/cedet/semantic/analyze/fcn.el 2012-12-17 18:17:13 +0000
> @@ -255,7 +255,7 @@
> (nexttype (semantic-analyze-dereference-metatype type scope type-declaration))
> (idx 0))
> (catch 'metatype-recursion
> - (while (and nexttype (not (eq (car nexttype) lasttype)))
> + (while (and nexttype (not (equal (car nexttype) lasttype)))
> (setq lasttype (car nexttype)
> lasttypedeclaration (cadr nexttype))
> (setq nexttype (semantic-analyze-dereference-metatype lasttype scope lasttypedeclaration))
> Tomasz Gajewski
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> cedet-semantic mailing list