Thread: [CEDET-devel] semantic-analizer : new C++ joy!
Brought to you by:
zappo
From: Eric M. L. <er...@si...> - 2007-01-25 03:30:04
|
Greetings all. The semantic analyzer, which is used in smart completions and other things, has worked ok for C and other simple languages, but has had issues for even mildly complex C++ files where namespaces are prevalent. With the advent of ebrowse support to parse the vast numbers of C++ headers I have at work, this missing feature had made the analyzer pretty much useless. I investigated the problem and discovered that, to my amazement, the solution was significantly simpler than I had anticipated! Checked into CVS for CEDET, please find updated C parser support, and a new version of the analyzer that can now correctly identify the scopes of method implementations within namespaces for C++. Also see two new C++ test files for subclasses which I was using to attempt to simplify the problem to something I could debug. I'll be giving this a try on some really big code soon to see if it can handle it. If you program in C++ please give the new combination of ebrowse/analyzer a try and let me know how it goes! Thanks, and Enjoy! Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Bruce S. <bru...@ce...> - 2007-02-14 22:43:12
|
"Eric M. Ludlam" <er...@si...> writes: [...] > If you program in C++ please give the new combination of > ebrowse/analyzer a try and let me know how it goes! It doesn't seem to work for me. There's a trivial showstopper: the version of ebrowse I've got (from emacs-snapshot, reported as ebrowse 22.0.93) doesn't seem to take space-separated filenames, it needs line-separated filenames. That's trivially fixed: diff -u -r1.7 semanticdb-ebrowse.el --- semantic/semanticdb-ebrowse.el 23 Jan 2007 02:18:32 -0000 1.7 +++ semantic/semanticdb-ebrowse.el 14 Feb 2007 22:25:22 -0000 @@ -99,7 +99,7 @@ (mapcar (lambda (f) (when (string-match regexp f) (insert f) - (insert " "))) + (insert "\n"))) files) ;; Cleanup the ebrowse output buffer. (save-excursion And then I get *BROWSE files that contain plausible things. But it doesn't seem that they're actually being used. As a test, I created a ~/test/ directory containing h and src directories. In the h directory I just copied ec.h from /usr/include/openssl, and in the src directory I stuck this file: #include "ec.h" void foo() { EC_GROUP_get_degree(); } Then I ran semanticdb-create-ebrowse-database on ~/test/h. And with POINT on the call to EC_GROUP_get_degree, I was hoping to get the prototype for it (after semanticdb had opened and parsed the file). But I don't get anything. If I explicitly visit ec.h, then I do get the prototype. C-c , J also doesn't offer any tags outside the current buffer, presumably for the same reason. (I note it's easy enough to get apparently duplicated databases. I seem to have files !home!bruce-test!test!h!BROWSE !home!bruce-test!test!h!BROWSE-load.el ~!test!hBROWSE ~!test!hBROWSE-load.el Shouldn't there be some canonicalisation?) So I guess there's something else I need to customize? Just to minimize the variables, I did this as a test user, so the .emacs is minimal: (setq semantic-load-turn-everything-on t) (load-file "/usr/source/CVS-cedet/cedet/common/cedet.el") (setq semanticdb-default-save-directory "~/.semanticdb") (custom-set-variables '(global-semantic-highlight-edits-mode t nil (semantic-util-modes)) '(global-semantic-idle-completions-mode t nil (semantic-idle)) '(global-semantic-stickyfunc-mode t nil (semantic-util-modes)) '(semantic-which-function-use-color t) '(semanticdb-project-roots (quote ("~/test")))) This probably sounds rather pessimistic, which doesn't match my impressions at all: I'm reasonably sure I'm missing an option somewhere or other. ebrowse itself runs quickly enough that I'm optimistic this'll be *really* useful to me. [...] |
From: Hannu K. <az...@ik...> - 2007-02-15 00:05:12
|
"Eric M. Ludlam" <er...@si...> writes: > Checked into CVS for CEDET, please find updated C parser support, > and a new version of the analyzer that can now correctly identify the > scopes of method implementations within namespaces for C++. > > Also see two new C++ test files for subclasses which I was using to > attempt to simplify the problem to something I could debug. > > I'll be giving this a try on some really big code soon to see if it > can handle it. I wanted to try this new goodness as well. A few observations. First I got this: idle error: "#<buffer hukka.cpp> - Symbol's function definition is void: semantic-dependency-find-file-on-path" [9 times] Apparently the only place that calls that function is semantic-tag-file.el. For some reason there are functions semantic-dependency-find-file-on-path and semantic--dependency-find-file-on-path in semantic-dep.el and _only the latter_ is autoloaded. I worked around by manually loading semantic-dep. semantic-idle-completions-mode doesn't seem to have any effect. I start getting "ifdef THREADS yes" messages, though, so I suspect this might be due to my CVS Emacs from 2005-12-18 being buggy. Maybe better forget this until I install a more recent Emacs. semantic-complete-analyze-inline gives me a popup window with completions but it immediately disappears. I also get "Bug Showing Completions: (wrong-type-argument integerp nil)" at some point. This might be a problem with my weird Emacs version as well, so I'll retry this when I install a more recent Emacs. semantic-ia-complete-* functions seem to work... for my small example project that doesn't use namespaces. Testing with a large project that uses namespaces wasn't so successful. I managed to reproduce the first problem I saw with a small example. Suppose I have foo.h as follows: --------------------------------------------------------------- class Kala { public: void kalasta() {} }; namespace a { namespace b { class Foo { public: void bar() { } void baz() { } }; } } --------------------------------------------------------------- And foo.cpp: --------------------------------------------------------------- #include "foo.h" namespace a { namespace c { void dum() { } } } --------------------------------------------------------------- Then I start experimenting inside dum(): void dum() { Ka<M-x semantic-ia-complete-symbol-menu RET> } results to "No completions available." Ok, maybe it's not supposed to complete class names in such a case. Let's continue void dum() { Kala kala; kala.<M-x semantic-ia-complete-symbol-menu RET> } works, i.e. gives me just one completion, kalasta(). Good. Next void dum() { b::Foo foo; foo.<M-x semantic-ia-complete-symbol-menu RET> } gives me bogus completions: dum () : void foo : Class b::Foo kala : Class Kala ...instead of bar() and baz(). Since the actual project is almost nothing but code that corresponds to this last case, it's not really meaningful to test further before this is fixed. -- Hannu |
From: Eric M. L. <er...@si...> - 2007-02-15 02:23:57
|
Hi, >>> Bruce Stephens <bru...@ce...> seems to think that: >"Eric M. Ludlam" <er...@si...> writes: [...] >> If you program in C++ please give the new combination of >> ebrowse/analyzer a try and let me know how it goes! > >It doesn't seem to work for me. > >There's a trivial showstopper: the version of ebrowse I've got (from >emacs-snapshot, reported as ebrowse 22.0.93) doesn't seem to take >space-separated filenames, it needs line-separated filenames. That's >trivially fixed: > >diff -u -r1.7 semanticdb-ebrowse.el >--- semantic/semanticdb-ebrowse.el 23 Jan 2007 02:18:32 -0000 1.7 >+++ semantic/semanticdb-ebrowse.el 14 Feb 2007 22:25:22 -0000 [ ... ] Thanks! I'll add that. [ ... ] >And then I get *BROWSE files that contain plausible things. > >But it doesn't seem that they're actually being used. Joakim pointed out that ebrowse wasn't working quite right in this situation the other day and I've been looking into it the last couple days to try and figure out how to make it work. The basic problem is that the ebrowse DB is set up as a "system" database. Thus, if you had: #include <ec.h> it would likely work. I'll try to explain without being too long-winded which I tend to do. This is also followup to Joakim's question from a few days ago. There are two classes of databases. DBs that provide full semantic information, such as the ones from the semantic parsers, and DBs that don't provide full info, such as ebrowse. Due to the lack of complete info from some system DBs, all tags from system DBs must be associated with the originating database so a given application can decide what to do with them. Programs that look within projects only all assume full tagging info, and also full lists. Having ebrowse provide that is no better than just having the regular semantic parsers provide them since that is the backup strategy. What I need to solve is how to integrate ebrowse for projects into the "search" part only, where tag lists are short and associated with a database. The pattern would be to look in regular semantic DB tables first, then EBrowse if a given table hasn't been parsed yet. I suspect the hard part is figuring out where the tiny bit of code is that needs to be tweaked. I chased the obvious thing a bit this afternoon and soon realized I was in the wrong API level. Ugh. Anyway, I also need to weigh that against the importance of getting CEDET 1.0 out which I would like to do soon since I keep encountering cool things to do that delay it. (Like this.) >As a test, I created a ~/test/ directory containing h and src >directories. In the h directory I just copied ec.h from >/usr/include/openssl, and in the src directory I stuck this file: > > #include "ec.h" > void > foo() > { > EC_GROUP_get_degree(); > } > [ ... ] >(I note it's easy enough to get apparently duplicated databases. I >seem to have files > > !home!bruce-test!test!h!BROWSE > !home!bruce-test!test!h!BROWSE-load.el > ~!test!hBROWSE > ~!test!hBROWSE-load.el > >Shouldn't there be some canonicalisation?) Huh. I haven't seen that before. The ~ should never show up in the file names there. How'd you do that? Thanks for the patch and report! I will be posting here when I eventually solve this problem. Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Eric M. L. <er...@si...> - 2007-02-15 03:12:53
|
Hi, >>> Hannu Koivisto <az...@ik...> seems to think that: >"Eric M. Ludlam" <er...@si...> writes: > >> Checked into CVS for CEDET, please find updated C parser support, >> and a new version of the analyzer that can now correctly identify the >> scopes of method implementations within namespaces for C++. >> >> Also see two new C++ test files for subclasses which I was using to >> attempt to simplify the problem to something I could debug. >> >> I'll be giving this a try on some really big code soon to see if it >> can handle it. > >I wanted to try this new goodness as well. A few observations. > >First I got this: > >idle error: "#<buffer hukka.cpp> - Symbol's function definition is > void: semantic-dependency-find-file-on-path" [9 times] > >Apparently the only place that calls that function is >semantic-tag-file.el. For some reason there are functions >semantic-dependency-find-file-on-path and >semantic--dependency-find-file-on-path in semantic-dep.el and _only >the latter_ is autoloaded. > >I worked around by manually loading semantic-dep. Huh. I see the obvious error, but wonder why I haven't seen this problem since adding the erroneous autoload. I'll fix it. >semantic-idle-completions-mode doesn't seem to have any effect. I >start getting "ifdef THREADS yes" messages, though, so I suspect >this might be due to my CVS Emacs from 2005-12-18 being buggy. >Maybe better forget this until I install a more recent Emacs. Ah, there is a debug message in semantic-c.el which I apparently forgot to remove. I'll remove that too. I had remembered to remove the "no" equivalent. ;) >semantic-complete-analyze-inline gives me a popup window with >completions but it immediately disappears. I also get "Bug Showing >Completions: (wrong-type-argument integerp nil)" at some point. >This might be a problem with my weird Emacs version as well, so >I'll retry this when I install a more recent Emacs. I happen to be running 2005-09-12, so your version isn't that weird. I've been meaning to upgrade for a while but I've been too lazy. The inline completion thingy uses a tooltip, so the popup will be a bit finicky. If you can repro with: M-x toggle-debug-on-error that would help narrow it down. >semantic-ia-complete-* functions seem to work... for my small example >project that doesn't use namespaces. > >Testing with a large project that uses namespaces wasn't so >successful. I managed to reproduce the first problem I saw with a >small example. Suppose I have foo.h as follows: Thanks for the examples. I will give this a detailed look on a day that isn't Valentine's day. ;) I use: M-x semantic-analyze-current-context when I encounter these problems because sometimes the output reveals things like missing entries from some scope or other. Thanks! Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Bruce S. <bru...@ce...> - 2007-02-15 12:15:21
|
"Eric M. Ludlam" <er...@si...> writes: [...] > The basic problem is that the ebrowse DB is set up as a "system" > database. Thus, if you had: > > #include <ec.h> > > it would likely work. Ah! I'd forgotten semantic-default-c-path, I think. Does that make sense? I think I'm beginning to get it to work, anyway. [...] >>(I note it's easy enough to get apparently duplicated databases. I >>seem to have files >> >> !home!bruce-test!test!h!BROWSE >> !home!bruce-test!test!h!BROWSE-load.el >> ~!test!hBROWSE >> ~!test!hBROWSE-load.el >> >>Shouldn't there be some canonicalisation?) > > Huh. I haven't seen that before. The ~ should never show up in the > file names there. How'd you do that? Just (semanticdb-create-ebrowse-database "~/test/h"). I see there's lots of use of expand-file-name in semanticdb-file.el, so I guess this ebrowse functionality is cunningly avoiding it, somehow. Hmm, it doesn't look as though semanticdb-file-name-directory makes its argument absolute. (Or that it's even supposed to (the docstring suggests it returns a relative directory, though if semanticdb-default-save-directory is non-nil the returned value will be an absolute pathname).) [...] |
From: Bruce S. <bru...@ce...> - 2007-02-15 14:04:54
|
Bruce Stephens <bru...@ce...> writes: [...] > Ah! I'd forgotten semantic-default-c-path, I think. Does that make > sense? I think I'm beginning to get it to work, anyway. Hmm, no. I think I must have read the file, or something. I find that with "#include <ec.h>" it doesn't work. But with "#include <../h/ec.h>" it does. So I guess there's something related to semantic-default-c-path going wrong for me. Ah, maybe not: without the ebrowse database set up, with ../h/ec.h, that file gets loaded and parsed. So I don't know what's wrong. Do I need to set semanticdb-find-default-throttle to anything magic? (It's '(project system recursive), which looks OK: I want to use the system database.) [...] |
From: Eric M. L. <er...@si...> - 2007-02-15 15:30:49
|
Hi, I've been poking at this a bit more today. This is just broken right now as the ebrowse database isn't participating unless it is off in /usr/include, or someplace far away like that. All the DBs are sorted by creation time. When we look up a file, I think the regular semantic DB gets hit first and is used, and we never see the ebrowse DB. I'll post to the mailing list when I figure something out. Eric >>> Bruce Stephens <bru...@ce...> seems to think that: >Bruce Stephens <bru...@ce...> writes: > >[...] > >> Ah! I'd forgotten semantic-default-c-path, I think. Does that make >> sense? I think I'm beginning to get it to work, anyway. > >Hmm, no. I think I must have read the file, or something. > >I find that with "#include <ec.h>" it doesn't work. But with >"#include <../h/ec.h>" it does. > >So I guess there's something related to semantic-default-c-path going >wrong for me. Ah, maybe not: without the ebrowse database set up, >with ../h/ec.h, that file gets loaded and parsed. > >So I don't know what's wrong. Do I need to set >semanticdb-find-default-throttle to anything magic? (It's '(project >system recursive), which looks OK: I want to use the system database.) [ ... ] |
From: Bruce S. <bru...@ce...> - 2007-02-15 21:06:51
|
"Eric M. Ludlam" <er...@si...> writes: > Hi, > > I've been poking at this a bit more today. This is just broken > right now as the ebrowse database isn't participating unless it is off > in /usr/include, or someplace far away like that. > > All the DBs are sorted by creation time. When we look up a file, I > think the regular semantic DB gets hit first and is used, and we never > see the ebrowse DB. Ah, OK, that makes sense. That's probably something I can work with---all I need is a separate checkout of my headers and things, which I need for other reasons anyway. [...] |
From: Eric M. L. <er...@si...> - 2007-02-15 19:46:33
|
>>> Bruce Stephens <bru...@ce...> seems to think that: >"Eric M. Ludlam" <er...@si...> writes: > >[...] > >> If you program in C++ please give the new combination of >> ebrowse/analyzer a try and let me know how it goes! [ ... ] > >But it doesn't seem that they're actually being used. > >As a test, I created a ~/test/ directory containing h and src >directories. In the h directory I just copied ec.h from >/usr/include/openssl, and in the src directory I stuck this file: > > #include "ec.h" > void > foo() > { > EC_GROUP_get_degree(); > } > >Then I ran semanticdb-create-ebrowse-database on ~/test/h. And with >POINT on the call to EC_GROUP_get_degree, I was hoping to get the >prototype for it (after semanticdb had opened and parsed the file). >But I don't get anything. If I explicitly visit ec.h, then I do get >the prototype. C-c , J also doesn't offer any tags outside the >current buffer, presumably for the same reason. I checked in a new version of semanticdb.el which allows ec.h from ebrowse to be used in this case. Depending on what you are trying to get help for this should work. I've recently found that large aspects of the ebrowse database are not accessible through semanticdb-ebrowse yet, so to debug use: M-x semanticdb-find-test-translate-path to see if problems you encounter getting symbol help is because of the DB being unavailable, or a bug in the database itself. >(I note it's easy enough to get apparently duplicated databases. I >seem to have files > > !home!bruce-test!test!h!BROWSE > !home!bruce-test!test!h!BROWSE-load.el > ~!test!hBROWSE > ~!test!hBROWSE-load.el > >Shouldn't there be some canonicalisation?) [ ... ] I also checked in a fix for this problem. Thanks! Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Eric M. L. <er...@si...> - 2007-02-22 03:36:30
|
Your below example was excellent. It exposed an area of namespaces that wasn't yet supported. I was able to fix the second problem in semantic-c.el, and semantic-analize.el such that it worked for your below example. If you could get the latest from CVS and let me know how it goes, I would be most appreciative. A good way to check when you encounter an issue is with: M-x semantic-analyze-current-context RET If the Prefix slot doesn't have any type information, then the rest of the system will fail. I also updated semantic-ia-complete-symbol-menu to use the senator menu as a backup. It got the answer correct for the "complete the class name" part with "Ka", though it just does pattern matching. Thanks Eric >>> Hannu Koivisto <az...@ik...> seems to think that: >"Eric M. Ludlam" <er...@si...> writes: > >> Checked into CVS for CEDET, please find updated C parser support, >> and a new version of the analyzer that can now correctly identify the >> scopes of method implementations within namespaces for C++. >> >> Also see two new C++ test files for subclasses which I was using to >> attempt to simplify the problem to something I could debug. >> >> I'll be giving this a try on some really big code soon to see if it >> can handle it. > >I wanted to try this new goodness as well. A few observations. > >First I got this: > >idle error: "#<buffer hukka.cpp> - Symbol's function definition is > void: semantic-dependency-find-file-on-path" [9 times] > >Apparently the only place that calls that function is >semantic-tag-file.el. For some reason there are functions >semantic-dependency-find-file-on-path and >semantic--dependency-find-file-on-path in semantic-dep.el and _only >the latter_ is autoloaded. > >I worked around by manually loading semantic-dep. > >semantic-idle-completions-mode doesn't seem to have any effect. I >start getting "ifdef THREADS yes" messages, though, so I suspect >this might be due to my CVS Emacs from 2005-12-18 being buggy. >Maybe better forget this until I install a more recent Emacs. > >semantic-complete-analyze-inline gives me a popup window with >completions but it immediately disappears. I also get "Bug Showing >Completions: (wrong-type-argument integerp nil)" at some point. >This might be a problem with my weird Emacs version as well, so >I'll retry this when I install a more recent Emacs. > >semantic-ia-complete-* functions seem to work... for my small example >project that doesn't use namespaces. > >Testing with a large project that uses namespaces wasn't so >successful. I managed to reproduce the first problem I saw with a >small example. Suppose I have foo.h as follows: > >--------------------------------------------------------------- >class Kala { >public: > void kalasta() {} >}; > >namespace a { >namespace b { > >class Foo { >public: > void bar() { } > void baz() { } >}; > >} >} >--------------------------------------------------------------- > >And foo.cpp: > >--------------------------------------------------------------- >#include "foo.h" > >namespace a { >namespace c { > >void dum() { >} > >} >} >--------------------------------------------------------------- > >Then I start experimenting inside dum(): > >void dum() { > Ka<M-x semantic-ia-complete-symbol-menu RET> >} > >results to "No completions available." Ok, maybe it's not supposed >to complete class names in such a case. Let's continue > >void dum() { > Kala kala; > > kala.<M-x semantic-ia-complete-symbol-menu RET> >} > >works, i.e. gives me just one completion, kalasta(). Good. Next > >void dum() { > b::Foo foo; > > foo.<M-x semantic-ia-complete-symbol-menu RET> >} > >gives me bogus completions: > dum () : void > foo : Class b::Foo > kala : Class Kala > >...instead of bar() and baz(). > >Since the actual project is almost nothing but code that >corresponds to this last case, it's not really meaningful to test >further before this is fixed. > -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Hannu K. <az...@ik...> - 2007-02-22 11:50:05
|
"Eric M. Ludlam" <er...@si...> writes: > Your below example was excellent. It exposed an area of namespaces > that wasn't yet supported. I was able to fix the second problem in > semantic-c.el, and semantic-analize.el such that it worked for your > below example. Sweet! > If you could get the latest from CVS and let me know how it goes, > I would be most appreciative. An attempt to build... # Because of "Makefile is out of date! It needs to be regenerated by EDE. # If you have not modified Project.ede, you can use touch to update # the Makefile time stamp." message touch **/Makefile make clean-autoloads make clean-all make EMACS=/usr/local/emacs-cvs/bin/emacs ...the CVS version results to: "/usr/local/emacs-cvs/bin/emacs" -batch --no-site-file -l grammar-make-script -f semantic-grammar-batch-build-packages semantic-grammar.wy Compiling Grammars from: /home/foo/cedet/semantic/semantic-grammar.el Package `semantic-grammar-wy' is up to date. In toplevel form: semantic-grammar-wy.el:365:14:Error: Apparently circular structure being printed make[1]: *** [metagrammar] Error 1 make[1]: Leaving directory `/home/foo/cedet/semantic' make: *** [semantic] Error 2 The sad part is that I actually faced the same problem the previous time and somehow managed to get rid of it but I no longer remember how... > A good way to check when you encounter an issue is with: > M-x semantic-analyze-current-context RET > > If the Prefix slot doesn't have any type information, then the rest of > the system will fail. Thanks for the tip. -- Hannu |
From: Eric M. L. <er...@si...> - 2007-02-22 13:37:28
|
>>> Hannu Koivisto <az...@ik...> seems to think that: >"Eric M. Ludlam" <er...@si...> writes: > >> Your below example was excellent. It exposed an area of namespaces >> that wasn't yet supported. I was able to fix the second problem in >> semantic-c.el, and semantic-analize.el such that it worked for your >> below example. > >Sweet! > >> If you could get the latest from CVS and let me know how it goes, >> I would be most appreciative. > >An attempt to build... > ># Because of "Makefile is out of date! It needs to be regenerated by EDE. ># If you have not modified Project.ede, you can use touch to update ># the Makefile time stamp." message >touch **/Makefile Yea, one thing I've learned is that I should have named the project file AProject.ede so that when a CVS checkout occurs, this doesn't happen. ;) >make clean-autoloads >make clean-all >make EMACS=/usr/local/emacs-cvs/bin/emacs > >...the CVS version results to: > >"/usr/local/emacs-cvs/bin/emacs" -batch --no-site-file -l grammar-make-script -f semantic-grammar-batch-build-packages semantic-grammar.wy >Compiling Grammars from: /home/foo/cedet/semantic/semantic-grammar.el >Package `semantic-grammar-wy' is up to date. > >In toplevel form: >semantic-grammar-wy.el:365:14:Error: Apparently circular structure being printed >make[1]: *** [metagrammar] Error 1 >make[1]: Leaving directory `/home/foo/cedet/semantic' >make: *** [semantic] Error 2 Hmmm. I haven't updated that file since last fall. >The sad part is that I actually faced the same problem the previous >time and somehow managed to get rid of it but I no longer remember how... I tried your steps in my checkout-only copy of cedet w/out being able to repro it. If, in Emacs, you use C-x v d ~/path/to/cedet RET it will let you know if any files related to that grammar are modified locally, or out of date. While I haven't seen that specific error, when someone bumps into a problem with that grammar file, I usually suggest that they delete it, and then "cvs up semantic-grammar-wy.el" to fetch a new one from CVS, and that has always worked. Thanks Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Hannu K. <az...@ik...> - 2007-02-22 14:16:35
|
"Eric M. Ludlam" <er...@si...> writes: >>"/usr/local/emacs-cvs/bin/emacs" -batch --no-site-file -l grammar-make-script -f semantic-grammar-batch-build-packages semantic-grammar.wy >>Compiling Grammars from: /home/foo/cedet/semantic/semantic-grammar.el >>Package `semantic-grammar-wy' is up to date. >> >>In toplevel form: >>semantic-grammar-wy.el:365:14:Error: Apparently circular structure being printed >>make[1]: *** [metagrammar] Error 1 >>make[1]: Leaving directory `/home/foo/cedet/semantic' >>make: *** [semantic] Error 2 > > Hmmm. I haven't updated that file since last fall. > >>The sad part is that I actually faced the same problem the previous >>time and somehow managed to get rid of it but I no longer remember how... > > I tried your steps in my checkout-only copy of cedet w/out being able > to repro it. > > If, in Emacs, you use > > C-x v d ~/path/to/cedet RET > > it will let you know if any files related to that grammar are modified > locally, or out of date. > > While I haven't seen that specific error, when someone bumps into a > problem with that grammar file, I usually suggest that they delete it, > and then "cvs up semantic-grammar-wy.el" to fetch a new one from CVS, > and that has always worked. I made a completely new checkout on a different machine (than my previous CEDET test) so that cannot be the issue. And I now explicitly checked it's up-to-date. I tested a bit more and apparently Debian's Emacs 21.4 can compile semantic-grammar-wy.el without that problem (I first tried with Emacs 22-CVS-20051218 which I have on this other machine as well) so it would seem to suggest that this is an Emacs problem. I only wonder how on earth I managed to get CEDET to build on my home machine with that same Emacs CVS version. Or maybe I built it with 21.4 and then used with the CVS version... Now that I tried it seems to work so I'll continue testing that way. Sorry for the noise, I guess I finally have to upgrade if I want to continue using the development version. Completion still doesn't work in my real case. I'll try to make an updated small test case that can be used to reproduce the problem. -- Hannu |
From: Hannu K. <az...@ik...> - 2007-02-23 13:56:20
|
"Eric M. Ludlam" <er...@si...> writes: > Your below example was excellent. It exposed an area of namespaces > that wasn't yet supported. I was able to fix the second problem in > semantic-c.el, and semantic-analize.el such that it worked for your > below example. > > If you could get the latest from CVS and let me know how it goes, > I would be most appreciative. The CVS version indeed worked for my example but it seems my example was too simple to correspond to the real case I was having problems with. Here's un updated version: ---foo.hpp-------------------------------------------------------- namespace a { namespace b { class Quux; } // namespace b b::Quux& getQuux(); } // namespace a ---foo.hpp-------------------------------------------------------- ---quux.hpp------------------------------------------------------- namespace a { namespace b { class Quux { public: void dum() { } void dam() { } }; } } ---quux.hpp------------------------------------------------------- ---foo.cpp-------------------------------------------------------- #include "foo.hpp" #include "quux.hpp" namespace a { namespace c { void dum() { b::Quux& theQuux = getQuux(); theQuux.<M-x semantic-ia-complete-symbol-menu> => bogus completions } } } ---foo.cpp-------------------------------------------------------- That is, within dum() in foo.cpp it can't complete b::Quux members but instead gives me: * getQuux () : class b::Quux * theQuux : class b::Quux > A good way to check when you encounter an issue is with: > M-x semantic-analyze-current-context RET This gives me: Context Type: #<semantic-analyze-context context> Bounds: (129 . 129) Prefix: class b::Quux theQuux "" Prefix Classes: 'function 'variable Prefix Types: 'nil -------- Scope Types: namespace a {} namespace c {} Scope: foo.hpp quux.hpp namespace a {} namespace a {} namespace b {} class b::Quux getQuux () namespace c {} LocalVars: class b::Quux theQuux -- Hannu |
From: Eric M. L. <er...@si...> - 2007-02-23 17:56:53
|
Hi, Thanks for the example. When I created those files, I got the dum/dam completions. Suspicious, I swapped the order of the #include statements, and then I replicated the problem you saw. One of the features I added to the analyzer recently for your examples was the ability to merge multiple namespace instances together. My suspicion at the time was that this could end up being very slow for very large namespaces, but in this case, it just isn't working. I'm going to investigate this problem, but I may end up getting side-tracked on some sort of namespace/type manager because dealing with it in the analyzer for every query is wasteful. As usual, I'll be posting about it as I go. Be a bit patient with me, as I feel it is important to get good C++ completion working for the CEDET 1.0 release, as without it, CEDET won't be very useful to C++ users. Thanks Eric >>> Hannu Koivisto <az...@ik...> seems to think that: >"Eric M. Ludlam" <er...@si...> writes: > >> Your below example was excellent. It exposed an area of namespaces >> that wasn't yet supported. I was able to fix the second problem in >> semantic-c.el, and semantic-analize.el such that it worked for your >> below example. >> >> If you could get the latest from CVS and let me know how it goes, >> I would be most appreciative. > >The CVS version indeed worked for my example but it seems my >example was too simple to correspond to the real case I was having >problems with. Here's un updated version: > >---foo.hpp-------------------------------------------------------- >namespace a { >namespace b { > >class Quux; > >} // namespace b > >b::Quux& getQuux(); > >} // namespace a >---foo.hpp-------------------------------------------------------- > >---quux.hpp------------------------------------------------------- >namespace a { >namespace b { > >class Quux { >public: > void dum() { } > void dam() { } >}; > >} >} >---quux.hpp------------------------------------------------------- > >---foo.cpp-------------------------------------------------------- >#include "foo.hpp" >#include "quux.hpp" > >namespace a { >namespace c { > >void dum() { > b::Quux& theQuux = getQuux(); > theQuux.<M-x semantic-ia-complete-symbol-menu> => bogus completions >} > >} >} >---foo.cpp-------------------------------------------------------- > >That is, within dum() in foo.cpp it can't complete b::Quux members >but instead gives me: > >* getQuux () : class b::Quux >* theQuux : class b::Quux > >> A good way to check when you encounter an issue is with: >> M-x semantic-analyze-current-context RET > >This gives me: > >Context Type: #<semantic-analyze-context context> >Bounds: (129 . 129) >Prefix: class b::Quux theQuux > "" >Prefix Classes: 'function > 'variable >Prefix Types: 'nil >-------- >Scope Types: namespace a {} > namespace c {} >Scope: foo.hpp > quux.hpp > namespace a {} > namespace a {} > namespace b {} > class b::Quux getQuux () > namespace c {} >LocalVars: class b::Quux theQuux > -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Eric M. L. <er...@si...> - 2007-02-23 20:57:03
|
Hi, Debugging your example was confusing, but I did discover that the prototype class was getting in the way of finding the real class. So I changed the C++ parser to mark the prototype as such. That still didn't work, so I spent some time just analyzing the analyzer, moving things around, adding comments and sections, and trying to simplify some things based on what I'd learned recently. Then I replaced all the comments like "we should be smarter here", with a new `semantic-analyze-select-best-tag' function. When I was done, your example worked as expected. Huzzah! Thanks again for the great example. Eric >>> Hannu Koivisto <az...@ik...> seems to think that: >"Eric M. Ludlam" <er...@si...> writes: > >> Your below example was excellent. It exposed an area of namespaces >> that wasn't yet supported. I was able to fix the second problem in >> semantic-c.el, and semantic-analize.el such that it worked for your >> below example. >> >> If you could get the latest from CVS and let me know how it goes, >> I would be most appreciative. > >The CVS version indeed worked for my example but it seems my >example was too simple to correspond to the real case I was having >problems with. Here's un updated version: [ ... ] -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Hannu K. <az...@ik...> - 2007-02-23 22:41:37
|
"Eric M. Ludlam" <er...@si...> writes: > Debugging your example was confusing, but I did discover that the > prototype class was getting in the way of finding the real class. So > I changed the C++ parser to mark the prototype as such. That still > didn't work, so I spent some time just analyzing the analyzer, moving > things around, adding comments and sections, and trying to simplify > some things based on what I'd learned recently. Then I replaced all > the comments like "we should be smarter here", with a new > `semantic-analyze-select-best-tag' function. When I was done, your > example worked as expected. Huzzah! Great work, current CVS version seems to work with my example indeed. Unfortunately my example still seems to be insufficient to model the problem with my real code :( I have tried to figure out what makes them different but so far I haven't come up with anything. However, I see something that puzzles me; maybe you could help me out with this. Let's look at foo.cpp again: ---foo.cpp-------------------------------------------------------- #include "foo.hpp" #include "quux.hpp" namespace a { namespace c { void dum() { b::Quux& theQuux = getQuux(); theQuux<M-x semantic-analyze-current-context> } } } ---foo.cpp-------------------------------------------------------- If I invoke semantic-analyze-current-context as indicated above, it tells me: * (1) Prefix: class b::Quux rWaveformStatusModel Prefix Classes: 'function 'variable -------- Now, if I add a dot after theQuux, i.e. theQuux.<M-x semantic-analyze-current-context> the scope remains identical but the info at the beginning changes to: * (2) Prefix: class b::Quux theQuux "" Prefix Classes: 'function 'variable Prefix Types: class Quux {} -------- When I do the same with my real code, the first case (without dot) is equivalent to (1) but the second one is equivalent to this: Prefix: "theQuux" "" Prefix Classes: 'function 'variable -------- Semantic seems to know the type in the first case since it is displayed after "Prefix:". If I add the dot it somehow no longer sees the type. Or maybe I'm just interpreting the output incorrectly and the existence of type after "Prefix:" doesn't really mean much. Are there any other functions except semantic-analyze-current-context that I could use to get information out of my case? I have stared contents of semanticdb-database-list and it looks reasonable to me but I could easily be missing something. -- Hannu |
From: Eric M. L. <er...@si...> - 2007-02-24 13:58:35
|
In real code, the part of the C parser that finds local variables may be confused, though I don't know why the "." would be related. for example, when I use your old example with semantic-analyze-current-context, I get: --------- Context Type: #<semantic-analyze-context context> Bounds: (202 . 202) Prefix: class b::Quux theQuux "" Prefix Classes: 'function 'variable Prefix Types: class Quux {} -------- Scope Types: namespace a {} namespace c {} Scope: quux.hpp foo.hpp namespace a {} [ SNIP ] class b::Quux getQuux () LocalVars: class b::Quux theQuux ---------- If LocalVars were empty, or excluded your variable then it would be unable to determine the class of Quux. Does that seem likely? Eric >>> Hannu Koivisto <az...@ik...> seems to think that: >"Eric M. Ludlam" <er...@si...> writes: > >> Debugging your example was confusing, but I did discover that the >> prototype class was getting in the way of finding the real class. So >> I changed the C++ parser to mark the prototype as such. That still >> didn't work, so I spent some time just analyzing the analyzer, moving >> things around, adding comments and sections, and trying to simplify >> some things based on what I'd learned recently. Then I replaced all >> the comments like "we should be smarter here", with a new >> `semantic-analyze-select-best-tag' function. When I was done, your >> example worked as expected. Huzzah! > >Great work, current CVS version seems to work with my example indeed. >Unfortunately my example still seems to be insufficient to model >the problem with my real code :( > >I have tried to figure out what makes them different but so far I >haven't come up with anything. However, I see something that >puzzles me; maybe you could help me out with this. > >Let's look at foo.cpp again: > >---foo.cpp-------------------------------------------------------- >#include "foo.hpp" >#include "quux.hpp" > >namespace a { >namespace c { > >void dum() { > b::Quux& theQuux = getQuux(); > theQuux<M-x semantic-analyze-current-context> >} > >} >} >---foo.cpp-------------------------------------------------------- > > >If I invoke semantic-analyze-current-context as indicated >above, it tells me: > >* (1) > >Prefix: class b::Quux rWaveformStatusModel >Prefix Classes: 'function > 'variable >-------- > >Now, if I add a dot after theQuux, i.e. > > theQuux.<M-x semantic-analyze-current-context> > >the scope remains identical but the info at the beginning changes >to: > >* (2) > >Prefix: class b::Quux theQuux > "" >Prefix Classes: 'function > 'variable >Prefix Types: class Quux {} >-------- > >When I do the same with my real code, the first case (without dot) >is equivalent to (1) but the second one is equivalent to this: > >Prefix: "theQuux" > "" >Prefix Classes: 'function > 'variable >-------- > >Semantic seems to know the type in the first case since it is >displayed after "Prefix:". If I add the dot it somehow no longer >sees the type. Or maybe I'm just interpreting the output >incorrectly and the existence of type after "Prefix:" doesn't >really mean much. > >Are there any other functions except >semantic-analyze-current-context that I could use to get >information out of my case? I have stared contents of >semanticdb-database-list and it looks reasonable to me but I could >easily be missing something. > -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Hannu K. <az...@ik...> - 2007-02-24 17:43:39
|
"Eric M. Ludlam" <er...@si...> writes: > In real code, the part of the C parser that finds local variables may > be confused, though I don't know why the "." would be related. for > example, when I use your old example with > semantic-analyze-current-context, I get: > > --------- > Context Type: #<semantic-analyze-context context> > Bounds: (202 . 202) > Prefix: class b::Quux theQuux > "" > Prefix Classes: 'function > 'variable > Prefix Types: class Quux {} > -------- > Scope Types: namespace a {} > namespace c {} > Scope: quux.hpp > foo.hpp > namespace a {} > > [ SNIP ] > > class b::Quux getQuux () > LocalVars: class b::Quux theQuux > ---------- > > If LocalVars were empty, or excluded your variable then it would be > unable to determine the class of Quux. > > Does that seem likely? In my real code LocalVars includes the variable in question whether I have "." or not. I don't know what on earth I did but I managed to reproduce the problem in _one Emacs session_ by altering my earlier example code into this: -- foo.cpp -------------------------------------------------- #include "foo.hpp" #include "kala.hpp" #define DUM(class, something) getQuux() namespace a { namespace c { void dum() { b::Quux& theQuux = DUM(b::Quux, foo); theQuux.<completion doesn't work here> } } } -- foo.cpp -------------------------------------------------- semantic-analyze-current-context produces: Context Type: #<semantic-analyze-context context> Bounds: (178 . 178) Prefix: class b::Quux theQuux "" Prefix Classes: 'function 'variable Prefix Types: 'nil -------- Scope Types: namespace a {} namespace c {} Scope: foo.hpp kala.hpp const DUM namespace a {} namespace a {} subdir/quux.hpp namespace c {} namespace b {} class b::Quux getQuux () namespace c {} LocalVars: class b::Quux theQuux -- foo.hpp -------------------------------------------------- namespace a { namespace b { class Quux; } // namespace b b::Quux& getQuux(); namespace c { class Sur { public: void test() const; }; } } // namespace a -- foo.hpp -------------------------------------------------- -- kala.hpp ------------------------------------------------- #include "subdir/quux.hpp" -- kala.hpp ------------------------------------------------- -- subdir/quux.hpp ------------------------------------------ namespace a { namespace b { class Quux { public: void kil() { } void kal() { } }; } } -- subdir/quux.hpp ------------------------------------------ But when I started a new Emacs and loaded those files it was able to do completion! I wish I could figure out how to make a solid example case :( -- Hannu |