Re: [CEDET-devel] support for external parsers
Brought to you by:
zappo
From: Eric M. L. <er...@si...> - 2011-04-13 23:42:08
|
On 04/13/2011 04:33 PM, David Engster wrote: > Eric M. Ludlam writes: >> On 04/12/2011 05:03 PM, David Engster wrote: >>> OK, this is pretty much working. I can add 'omniscience' to the >>> semanticdb-find-default-throttle and the new semanticdb-clang will be >>> queried. However, this is not working when completing type members, >>> since here only tags in the current scope will be searched, and >>> semanticdb won't be queried at all. How can I make semantic search my >>> semanticdb-clang for every completion task? Do I have to override >>> semantic-analyze-possible-completions for that? > > [...] > >> I'll take a wild guess that if you run clang on some file, it gives you >> all tags accessible via header files too. (thus the omniscient version >> being needed.) > > You're guessing right. In a nutshell, you simply say to clang "Give me > all possible completions for that C++ source file at line X, column Y". > Using the LLVM compiler back end, it is able to fully parse the file > with all #include's and give you this list. I first thought that this > would be slow with lots of headers, but somehow it isn't (it doesn't do > any actual compilation, but still it's surprising how fast it actually > is). > >> In that case, just add it to a buffer-local copy of >> semanticdb-project-system-databases, presumably at the end. > > This is exactly what I did (I took the GNU global semanticdb as a > template). The problem I tried to describe is that this is not working > for type members, for example: > > void f() { > struct someStruct {int a; int b;}; > someStruct foo; > foo. // complete here > } > > The semanticdb won't be queried here, because > semantic-analyze-possible-completions will only look in the current > scope: > > (if completetexttype > > (setq c (semantic-find-tags-for-completion > completetext > (semantic-analyze-scoped-type-parts completetexttype scope) > )) While looking up "foo", it should identify it as type "someStruct". Somestruct is local, so it should never hit the omniscient database. If you do semantic-calculate-scope, you can figure out what the scope there is. It should include someStruct with parts. If you put someStruct into a header, and use `semantic-adebug-analyze' you get the expandable version of semantic-analyze-current-context. In that context, open the prefixtypes, and look at somestruct. You'll be able to see the origin of the tag, and perhaps figure out what went wrong. (ie - you have a struct with no members in it?) >> In this case, you will have an exciting time making sure >> semanticdb-normalize-tags works properly. If this is your dependency, >> then you will also need some trick to disable the usual tag lookup >> system. I'd have to think about that to figure it out. > > Yes, but I think we can cross that bridge when we get there. :-) Tags that don't get normalized cause problems when deriving complex sequences, like "this.that.theother", such that if "that" has a type in a tag that doesn't get normalized correctly, you may not find it's type, or the localized scope can get messed up and miss information. This sounds like a cool project. It would be nice if it worked. Eric |