CEDET

My mistake on previous email.

Here the first A is in scope, because bar::xx is in the second A
namespace.  I've updated the scope calculator to find and use the
merged A namespace instead of only the namespace block that bar::xx
shows up in.

If bar had been outside of A, like this:

void A::bar::xx() ...

then it would have worked since A::bar would have used the merged
version of A in the internal searches.

Eric

>>> Ravikiran Rajagopal <ravi.rajagopal@...> seems to think that:
>Hello,
>  The C++ parser does not seem to use namespaces when resolving names for 
>auto-completion. Here is a simple example:
>
>--------------------
>namespace A { class foo { public: void aa(); void bb(); };}
>namespace A { 
>class bar { public: void xx(); public: foo myFoo; };
>void bar::xx()
>{
>  myFoo. // <--- cursor is here after the dot
>}
>}
>--------------------
>
>Using the CVS version of CEDET on Emacs CVS (23.0.60), the analysis finds that 
>the variable "myFoo" is of type "foo", but it cannot find a definition of 
>type "foo" since it does not match "A::foo" as the same "foo" in the 
>declaration of class "bar". Without the "namespace" declarations, the type is 
>parsed correctly and the possible completions are presented. Could someone 
>kindly point me in the right direction to fix this problem? I am an elisp 
>novice (know just enough to muck with my .emacs) but very comfortable with 
>C++; please point me in the direction of documentation if this is known.
>
>Regards,
>Ravi
>

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

>>> Ravikiran Rajagopal <ravi.rajagopal@...> seems to think that:
>[Removed cedet-devel as the following is semantic-specific.]
>
>On Monday 24 March 2008 07:03:08 pm Eric M. Ludlam wrote:
>> I've updated the scope calculator to find and use the
>> merged A namespace instead of only the namespace block that bar::xx
>> shows up in.
>
>Thank you; the simple test case works. However, I have a more complex case 
>which does not work yet. Once I isolate the problem further, I will send you 
>a new case. Should I regenerate all the cached databases after your last 
>change?

The database files only contain the raw tags.  Part of the analysis
step is to create a typecache that merges all known types into a
single searchable table.  That table gets rebuilt whenever semantic
detects a change somewhere.

When in doubt, do this:

C-u M-x bovinate RET

to get all such caches flushed out.

>I have also been playing with gccxml which handles virtually every C++ parsing 
>case I have thrown at it (better than Eclipse CDT, KDevelop, Visual C++ 2008 
>Express) and produces very nice XML output which can be parsed very easily. 
>The main drawbacks are that only instantiated templates are output and that 
>incremental parsing is impossible. How difficult would it be to add a new 
>back end (a la ebrowse) into semantic? Again, I am a novice at elisp but 
>could whip up a python script fairly easily to massage the XML into virtually 
>any sort of output.
  [ ... ]

I've been reading about that, and hoping to try it out sometime.
The only restriction on a Semantic parser is that it can be done with
a single function that returns tags.  The texi parser is a good
example.  It's setup is like this:

  (semantic-install-function-overrides
   '((parse-region . semantic-texi-parse-region)
     (parse-changes . semantic-texi-parse-changes)))

If the gcc->xml->python->elisp cycle is fast, then an incremental
parser is likely still possible, even mixing the existing semantic
parser with the gcc one for full buffer parsing.

The first step would be an external script that creates something that
Emacs can call `read' on.  There is a chapter in the semantic appdev
manual for Tag basics.  It describes the output format.

The second step is to read in that stream, then 'cook' the tags into
something Semantic can create overlays for.

If that all works out, a script that builds database files for Emacs
to read in would be the bit that would really speed things up.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net