Sorry for the delay in responding.
An interesting tactic. I hadn't thought of using the
`semantic-deep-find-tags-by-name' as a way of resolving this issue.
To solve the problem of "what if it is in a header", perhaps what is
needed is a new utility such as "calculate-scope-for-tag". It could
visit the tag (TYPE in this case) and calculate a scope there, but only
iff the first call to semantic-analyze-find-tag failed. What would be
cool then is that the calculated scope would contain all the remainder
information actually needed for this mapping function due to recursion.
Hmmm. Complicated. Nifty.
A useful goal is keeping this inherited-tag-map function simple if
Due to the iterative nature of this routine, using
semantic-elp-analyze on some test code for before/after effects will
help track performance issues early.
And now you know why it takes me so long to fix bugs like this. :)
On Thu, 2009-07-23 at 16:14 +0200, David Engster wrote:
> Hi Eric,
> Eric M. Ludlam <eric@...> writes:
> > The function in question is semantic-analyze-scoped-inherited-tag-map,
> > around line 595 where it calls back out to the analyzer to find the
> > tag. The SCOPE that is passed in is the scope for where the
> > completion is being done, while it probably should be the scope for
> > where the type TYPE is. I have no idea what would happen if you
> > create a scope for some other location while fabricating a local
> > scope.
> Ah, OK. I'm not so sure semantic-scope is the right place, since at
> least to me this problem seems fairly specific to C++, and therefore
> should better go into semantic-c?
> Anyway, I played around with semantic-analyze-scoped-inherited-tag-map,
> and if the namespaces are declared in the same file I can simply get
> them from TYPE's scope:
> --- a/semantic/semantic-scope.el
> +++ b/semantic/semantic-scope.el
> @@ -583,7 +583,7 @@ whose tags can be searched when needed, OR it may be a scope object."
> ;; interfaces. Inheriting from an interfaces implies
> ;; you have a copy of all methods locally. I think.
> (parents (semantic-tag-type-superclasses type))
> - ps pt
> + ps newps pt sc
> (dolist (p parents)
> (setq ps (cond ((stringp p) p)
> @@ -592,7 +592,21 @@ whose tags can be searched when needed, OR it may be a scope object."
> ((and (listp p) (stringp (car p)))
> pt (condition-case nil
> - (semantic-analyze-find-tag ps 'type scope)
> + (progn
> + (setq newps ps)
> + (when (and (stringp (semantic-analyze-split-name ps))
> + (setq sc (semantic-scope-tag-get-scope type))
> + (setq sc (reverse (semantic-find-tags-by-type "namespace" sc))))
> + (while sc
> + ;; Check if parent is member of that namespace.
> + (when (semantic-deep-find-tags-by-name
> + ps (semantic-tag-type-members (car sc)))
> + (when (stringp (setq newps (semantic-analyze-split-name newps)))
> + (setq newps (list newps)))
> + ;; Make it fully qualified
> + (setq newps (semantic-analyze-unsplit-name (append (list (semantic-tag-name (car sc))) newps))))
> + (setq sc (cdr sc))))
> + (semantic-analyze-find-tag newps 'type scope))
> (error nil)))
> (when pt
> (funcall fcn pt)
> However, I'm not sure what to do when the namespaces are declared in an
> external header.
> > What I like about your patch is the idea of converting things into a
> > fully qualified name. It seems like it would simplify several problems.
> > Doing so, however, doesn't seem to make it possible to skip the task I
> > mention above, as there are many ways to say the same thing, and you
> > have to search each possibility as opposed to just guessing at one
> > particular solution.
> Well, I'm not really guessing, since the namespace is given in the
> type-declaration (which has a fully qualified name). Also, the
> dereferencer was at least able to deal with the posted problem without
> any change to semantic-scope.
> > Anyway, that's what I know off the top of my head. I didn't analyze
> > your patch as my kids keep interrupting and I can't seem to keep a
> > straight thought in my head today.
> Yet another problem with child classes... ;-)
> Cedet-devel mailing list