CEDET

On 10/11/2012 01:16 PM, Liu Binsheng wrote:
> Hi,
>
> When I use semantic-ia-complete-symbol, it signals an error
> "semantic-analyze-possible-completions-default: Cannot find types for
> `vector vec'" in the *Message* buffer.
>
> I removed all my semanticdb files to let semantic parse the headers
> again. But when I issued the command, the error occured immediately
> after the local files were parsed. And the completion for local
> symbols works fine. Maybe there's something wrong in parsing the
> system include files, but I'm not sure. Following is the c++ code.
>
> #include<vector>
> using namespace std;
>
> int main()
> {
> 	vector<int>  vec;
> 	vec.
> }
>
> And toggle-debug-on-error output:
>
> Debugger entered--Lisp error: (error "Cannot find types for `vector vec'")
>    signal(error ("Cannot find types for `vector vec'"))
>    error("Cannot find types for `%s'" "vector vec")
>    semantic-analyze-possible-completions-default([object semantic-analyze-context "context" (77 . 77) (("vec" variable ... ... [55 71]) "") (function variable type) (nil) [object semantic-scope-cache "Cache" [object semanticdb-table "main.cpp" [object semanticdb-project-database-file "test/" "/home/chris/code/cpp/test/" semanticdb-table nil ... "/home/chris/.emacs.d/semanticdb/!home!chris!code!cpp!test!semantic.cache" "2.0" "2.1beta"] c++-mode ... nil [object semanticdb-find-search-index "#<semanticdb-table main.cpp>  index" #2 ... [object semanticdb-typecache "/home/chris/code/cpp/test/main.cpp" nil nil nil ...]] ... "main.cpp" nil nil 80 289 ... ... nil] ("main" function ... nil #<overlay from 41 to 79 in main.cpp>) nil nil nil nil nil nil (...) nil] #<buffer main.cpp>  nil] nil)
>    semantic-analyze-possible-completions([object semantic-analyze-context "context" (77 . 77) (("vec" variable ... ... [55 71]) "") (function variable type) (nil) [object semantic-scope-cache "Cache" [object semanticdb-table "main.cpp" [object semanticdb-project-database-file "test/" "/home/chris/code/cpp/test/" semanticdb-table nil ... "/home/chris/.emacs.d/semanticdb/!home!chris!code!cpp!test!semantic.cache" "2.0" "2.1beta"] c++-mode ... nil [object semanticdb-find-search-index "#<semanticdb-table main.cpp>  index" #2 ... [object semanticdb-typecache "/home/chris/code/cpp/test/main.cpp" nil nil nil ...]] ... "main.cpp" nil nil 80 289 ... ... nil] ("main" function ... nil #<overlay from 41 to 79 in main.cpp>) nil nil nil nil nil nil (...) nil] #<buffer main.cpp>  nil])
>    semantic-ia-complete-symbol(77)
>    call-interactively(semantic-ia-complete-symbol t nil)
>    execute-extended-command(nil)
>    call-interactively(execute-extended-command nil nil)
>
> How can I fix this? Thanks in advance for any help.


Hi,

   I tried you sample code, and it worked fine for me, providing 37 
possible completions.

   Your best bet is to use:

M-x semantic-analyze-debug-assist RET

This command appears to have lost it's autoload cookie in CEDET/BZR, so 
you may need to (require 'semantic/analyze/debug) to get the function.

This will dump out all the possible reasons it can't find vec, and 
perhaps one of them will identify a lost header or something that will 
help you fix things.

Good Luck
Eric

On Thu, Oct 11, 2012 at 10:02:05PM -0400, Eric M. Ludlam wrote:
> On 10/11/2012 01:16 PM, Liu Binsheng wrote:
> > Hi,
> >
> > When I use semantic-ia-complete-symbol, it signals an error
> > "semantic-analyze-possible-completions-default: Cannot find types for
> > `vector vec'" in the *Message* buffer.
> >
> > I removed all my semanticdb files to let semantic parse the headers
> > again. But when I issued the command, the error occured immediately
> > after the local files were parsed. And the completion for local
> > symbols works fine. Maybe there's something wrong in parsing the
> > system include files, but I'm not sure. Following is the c++ code.
> >
> > #include<vector>
> > using namespace std;
> >
> > int main()
> > {
> > 	vector<int>  vec;
> > 	vec.
> > }
> >
> > And toggle-debug-on-error output:
> >
> > Debugger entered--Lisp error: (error "Cannot find types for `vector vec'")
> >    signal(error ("Cannot find types for `vector vec'"))
> >    error("Cannot find types for `%s'" "vector vec")
> >    semantic-analyze-possible-completions-default([object semantic-analyze-context "context" (77 . 77) (("vec" variable ... ... [55 71]) "") (function variable type) (nil) [object semantic-scope-cache "Cache" [object semanticdb-table "main.cpp" [object semanticdb-project-database-file "test/" "/home/chris/code/cpp/test/" semanticdb-table nil ... "/home/chris/.emacs.d/semanticdb/!home!chris!code!cpp!test!semantic.cache" "2.0" "2.1beta"] c++-mode ... nil [object semanticdb-find-search-index "#<semanticdb-table main.cpp>  index" #2 ... [object semanticdb-typecache "/home/chris/code/cpp/test/main.cpp" nil nil nil ...]] ... "main.cpp" nil nil 80 289 ... ... nil] ("main" function ... nil #<overlay from 41 to 79 in main.cpp>) nil nil nil nil nil nil (...) nil] #<buffer main.cpp>  nil] nil)
> >    semantic-analyze-possible-completions([object semantic-analyze-context "context" (77 . 77) (("vec" variable ... ... [55 71]) "") (function variable type) (nil) [object semantic-scope-cache "Cache" [object semanticdb-table "main.cpp" [object semanticdb-project-database-file "test/" "/home/chris/code/cpp/test/" semanticdb-table nil ... "/home/chris/.emacs.d/semanticdb/!home!chris!code!cpp!test!semantic.cache" "2.0" "2.1beta"] c++-mode ... nil [object semanticdb-find-search-index "#<semanticdb-table main.cpp>  index" #2 ... [object semanticdb-typecache "/home/chris/code/cpp/test/main.cpp" nil nil nil ...]] ... "main.cpp" nil nil 80 289 ... ... nil] ("main" function ... nil #<overlay from 41 to 79 in main.cpp>) nil nil nil nil nil nil (...) nil] #<buffer main.cpp>  nil])
> >    semantic-ia-complete-symbol(77)
> >    call-interactively(semantic-ia-complete-symbol t nil)
> >    execute-extended-command(nil)
> >    call-interactively(execute-extended-command nil nil)
> >
> > How can I fix this? Thanks in advance for any help.
> 
> 
> Hi,
> 
>    I tried you sample code, and it worked fine for me, providing 37 
> possible completions.
> 
>    Your best bet is to use:
> 
> M-x semantic-analyze-debug-assist RET
> 
> This command appears to have lost it's autoload cookie in CEDET/BZR, so 
> you may need to (require 'semantic/analyze/debug) to get the function.
> 
> This will dump out all the possible reasons it can't find vec, and 
> perhaps one of them will identify a lost header or something that will 
> help you fix things.
> 
> Good Luck
> Eric
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic

Thanks your reply Eric. I tried semantic-analyze-debug-assist, and
got the result:

--begin--
Unable to find datatype for: "class vector vec".
Declared type is: "class vector {}"
Raw data type is: ("vector" type (:template-specifier (("int" type nil nil nil)) :type "class") nil nil)

Semantic could not find this data type in any of its global tables.

Semantic locates datatypes through either the local scope, or the global
typecache.

Local Scope Information:
 * Tag Class Constraint against SCOPE: (type)
 * No known parents in current scope.
 * No known symbols currently in scope.
 * No known symbols declared locally.
Semantic creates and maintains a type cache for each buffer.
If the type is a global type, then it should appear in they typecache.
To examine the typecache, type:

  M-x semanticdb-typecache-dump RET   [ Do It ]

Current typecache Statistics:
      0 types global in this file
      0 types from includes.

If the datatype is not in the typecache, then your include
path may be incorrect.  

Include Path Summary:

The system include path is:
  /usr/include
  /usr/lib/gcc/i486-linux-gnu/4.7/include/
  /usr/local/include/
  /usr/lib/gcc/i486-linux-gnu/4.7/include-fixed/
  /usr/include/i386-linux-gnu/
  /usr/include/
  /usr/include/c++/4.7/
  /usr/include/c++/4.7/i486-linux-gnu/
  /usr/include/c++/4.7/backward/


Include Summary: /home/chris/code/cpp/test/vec.cpp

vec.cpp contains 1 includes.
   Unknown Includes:  0
   Unparsed Includes: 1
   Parsed Includes:   0

A likely cause of an unfound tag is missing include files.
The following includes were not found:
  vector

You can fix the include path for c++-mode by using this function:

M-x semantic-customize-system-include-path RET   [ Do It ]

which customizes the mode specific variable for the mode-local
variable `semantic-dependency-system-include-path'.
--end--

Obviously the header <vector> is /usr/include/c++/4.7/vector. I don't
know why semantic said vector was not found.

I also tried to trace semantic-fetch-tags by running
semantic-force-refresh. And it seemed that vector was found.

======================================================================
1 -> semantic-fetch-tags: 
1 <- semantic-fetch-tags: (("vector" include (:system-flag t) (dependency-file "/usr/include/c++/4.7/vector") #<overlay from 1 to 18 in vec.cpp>) (#1="std" using (:type (#1# type (:prototype t :type "namespace") nil nil)) nil #<overlay from 19 to 39 in vec.cpp>) ("main" function (:type "int") nil #<overlay from 40 to 79 in vec.cpp>))
======================================================================

BTW, I ran emacs with -Q, and then evaluated the cedet configuration
buffer, but the result was same.

I still can't find the reason that causes the problem. What else can I
do to fix this?
-- 
Liu Binsheng <liubinsheng@...>

On 10/12/2012 08:41 AM, Liu Binsheng wrote:
> vec.cpp contains 1 includes.
>     Unknown Includes:  0
>     Unparsed Includes: 1
>     Parsed Includes:   0
>
> A likely cause of an unfound tag is missing include files.
> The following includes were not found:
>    vector

[...]

> --end--
>
> Obviously the header<vector>  is /usr/include/c++/4.7/vector. I don't
> know why semantic said vector was not found.
>
> I also tried to trace semantic-fetch-tags by running
> semantic-force-refresh. And it seemed that vector was found.

It looks like it knows about your include, but didn't bother parsing it. 
  Unparsed includes are include files where it knows where it is, but 
didn't bring it it.

What it does is controlled with the variable:

semanticdb-find-default-throttle

which needs to include 'system' so it will pull in your system headers. 
  That is there by default, so I'm not sure why it would be different 
for you.

I use global-semantic-idle-scheduler-mode, which is in by default for 
semantic-mode if you use Emacs integrated CEDET.  That tends to make 
sure misc headers and typecaches are built and ready to go when you need 
them.

Are all those things enabled for you?

Eric

Liu Binsheng writes:
> (semantic-mode 1)
> (require 'semantic/bovine/c)

Remove the require. Then delete everything .emacs.d/semanticdb and try
again.

-David

Liu Binsheng writes:
> Include Path Summary:
>
> The system include path is:
>   /usr/include
>   /usr/lib/gcc/i486-linux-gnu/4.7/include/
>   /usr/local/include/
>   /usr/lib/gcc/i486-linux-gnu/4.7/include-fixed/
>   /usr/include/i386-linux-gnu/
>   /usr/include/
>   /usr/include/c++/4.7/
>   /usr/include/c++/4.7/i486-linux-gnu/
>   /usr/include/c++/4.7/backward/
>
>
> Include Summary: /home/chris/code/cpp/test/vec.cpp
>
> vec.cpp contains 1 includes.
>    Unknown Includes:  0
>    Unparsed Includes: 1
>    Parsed Includes:   0

Could you please try the following: Put

(add-to-list 'magic-fallback-mode-alist '("^// " . c++-mode))
(add-to-list 'magic-fallback-mode-alist '("^#include" . c++-mode))

into your .emacs, delete everything in .emacs.d/semanticdb and try
again.

The long story:

Semantic should find the vector-include in the above paths, and I also
think it does. My guess is that the file 'vector' is not recognized as
being a C++ file, so the Semantic parser does not kick in.

As you know, the C++ STL includes do not have an extension (it's one of
those things only a committee could come up with, since it solves a
problem by creating bigger ones). The main issue is of course that Emacs
cannot easily see that this is a C++ file. The glibc STL has magic
comments like "-*- C++ -*-" in the first line (other STLs don't have
that, of course, since they couldn't care less about Emacs).

While you *are* using glibc, I recently experienced similar problems
which are probably due to some change in how those file-local variables
are handled in Emacs (their handling is notoriously difficult since they
can pose a security risk). To make things more complicated, Semantic
disables all kinds of stuff when loading files to speed things up; this
includes how file-local variables are handled (otherwise Emacs might ask
about them during load).

We need to properly fix that; the above is just a workaraound.

-David

David Engster writes:
> Could you please try the following: Put
>
> (add-to-list 'magic-fallback-mode-alist '("^// " . c++-mode))
> (add-to-list 'magic-fallback-mode-alist '("^#include" . c++-mode))
>
> into your .emacs, delete everything in .emacs.d/semanticdb and try
> again.

You could also just try latest CEDET from bzr. I've just pushed a change
which I think should fix this issue.

-David

On Sat, Oct 27, 2012 at 09:56:38PM +0200, David Engster wrote:
> David Engster writes:
> > Could you please try the following: Put
> >
> > (add-to-list 'magic-fallback-mode-alist '("^// " . c++-mode))
> > (add-to-list 'magic-fallback-mode-alist '("^#include" . c++-mode))
> >
> > into your .emacs, delete everything in .emacs.d/semanticdb and try
> > again.
> 
> You could also just try latest CEDET from bzr. I've just pushed a change
> which I think should fix this issue.
> 
> -David
> 
> ------------------------------------------------------------------------------
> WINDOWS 8 is here. 
> Millions of people.  Your app in 30 days.
> Visit The Windows 8 Center at Sourceforge for all your go to resources.
> http://windows8center.sourceforge.net/
> join-generation-app-and-make-money-coding-fast/
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic

Thank you David!

Your analysis is correct, and both the workaround and latest CEDET work.
-- 
Liu Binsheng <liubinsheng@...>