Thread: [CEDET-devel] calculation of scope and position in file
Brought to you by:
zappo
From: David E. <de...@ra...> - 2009-07-20 23:05:36
|
Hi Eric, another small question: Consider this code snippet ----------------------- #include <iostream> int main(void) { cout << "test"; return 0; } using namespace std; ----------------------- If I put the cursor on "cout" and call semantic-calculate-scope, I get ] scopetypes #<TAG LIST: 1 entries> * std : namespace but the 'using namespace std;' statement does not apply to the code preceding it. Is this a misunderstanding of mine regarding scope, a principal limitation in the parses, or maybe a bug? -David |
From: Eric M. L. <er...@si...> - 2009-07-21 01:13:33
|
This is a problem with how the completion engine has been simplified. It is assumed most code is: ---- includes/imports declarations fcns ----- and when a request for completion/scope is called, it just asks "give me all the * in this file" The only time order is used is when scope is parsed upwards out of a function. (ie, each level of code/scope in the function) Compilers make decisions based on the current state at the time of the calculation. The Emacs Lisp parser isn't fast enough to make a decision like that by reparsing everything that comes before, so I parse everything up ahead of time, store the results, and then query the database. It might make sense to add some sort of scoped search function that says "give me all the * in this file before POINT". One thing that I've gathered from many email, however, is that refusal to make a completion decision based on some filter like that often makes folks confused or cranky, so why bother? :) If, in your example below, it is getting the *wrong* answer among several possible answers, then there is probably some sort of order-priority that could be used to fix it. If it only that there is an answer when there shouldn't be, it is probably best to leave it be. I've often wanted to convert the parsers in Semantic to underline bad stuff like that in red as you type. In that case, this should definitely be something worth fixing. Eric On Tue, 2009-07-21 at 01:05 +0200, David Engster wrote: > Hi Eric, > > another small question: Consider this code snippet > > ----------------------- > #include <iostream> > > int main(void) > { > cout << "test"; > return 0; > } > using namespace std; > ----------------------- > > If I put the cursor on "cout" and call semantic-calculate-scope, I get > > ] scopetypes #<TAG LIST: 1 entries> > * std : namespace > > but the 'using namespace std;' statement does not apply to the code > preceding it. Is this a misunderstanding of mine regarding scope, a > principal limitation in the parses, or maybe a bug? > > -David |
From: David E. <de...@ra...> - 2009-07-21 06:37:12
|
Eric M. Ludlam <er...@si...> writes: > If, in your example below, it is getting the *wrong* answer among > several possible answers, then there is probably some sort of > order-priority that could be used to fix it. If it only that there is > an answer when there shouldn't be, it is probably best to leave it be. Hi Eric, Thank you for the explanation. I stumbled upon this with the following test case: -------------------------- namespace foo { struct test{ int one; }; } namespace bar { struct test{ int two; }; } using namespace foo; int main(void) { test f; f. } using namespace bar; --------------------------- In this case, semantic puts namespace 'bar' *before* 'foo' in scope, so that "f." completes to "f.two". Even worse, this also happens with --------------------------- int main(void) { using namespace foo; test f; f. } using namespace bar; --------------------------- As you say, this could be fixed by returning the namespaces in the correct order. I guess this has to be done in the ctxt-scoped-types override? I'll look into this after work. Regards, David |
From: David E. <de...@ra...> - 2009-07-22 19:05:18
|
Hi Eric, David Engster <de...@ra...> writes: > Eric M. Ludlam <er...@si...> writes: >> If, in your example below, it is getting the *wrong* answer among >> several possible answers, then there is probably some sort of >> order-priority that could be used to fix it. If it only that there is >> an answer when there shouldn't be, it is probably best to leave it be. > Thank you for the explanation. I stumbled upon this with the following > test case: [...] > As you say, this could be fixed by returning the namespaces in the > correct order. I guess this has to be done in the ctxt-scoped-types > override? I'll look into this after work. Actually, the tags get sorted alphabetically in semanticdb-typecache-merge-streams. I removed the call to semantic-sort-tags-by-name-then-type-increasing there and now I get the tags according to the order they appear in the buffer. I'm not sure why the tags get sorted alphabetically in the first place; is it just so that they are more clearly arranged for the user? Then I'd argue the sorting should happen in the higher level functions. -David |
From: Eric M. L. <er...@si...> - 2009-07-23 00:32:43
|
On Wed, 2009-07-22 at 21:05 +0200, David Engster wrote: > Hi Eric, > > David Engster <de...@ra...> writes: > > Eric M. Ludlam <er...@si...> writes: > >> If, in your example below, it is getting the *wrong* answer among > >> several possible answers, then there is probably some sort of > >> order-priority that could be used to fix it. If it only that there is > >> an answer when there shouldn't be, it is probably best to leave it be. > > > Thank you for the explanation. I stumbled upon this with the following > > test case: > > [...] > > > As you say, this could be fixed by returning the namespaces in the > > correct order. I guess this has to be done in the ctxt-scoped-types > > override? I'll look into this after work. > > Actually, the tags get sorted alphabetically in > semanticdb-typecache-merge-streams. I removed the call to > semantic-sort-tags-by-name-then-type-increasing there and now I get the > tags according to the order they appear in the buffer. > > I'm not sure why the tags get sorted alphabetically in the first place; > is it just so that they are more clearly arranged for the user? Then I'd > argue the sorting should happen in the higher level functions. Hi, The tags are sorted to simplify the task of the merge. If you have the following from a mix of headers: namespace std {} namespace mystuff {} namespace std {} then the merge process is simplified by first sorting because all the std{} spaces are next to eachother in the master list. The Emacs 'sort' function is pretty fast. I had contemplated creating a hash table or obarray for this task, but this seemed like the conceptually easiest thing to do. The reason to merge is to simplify searching. Step 1, find 'std' (or whatever), step 2 get the children and search those. If there were multiple 'std' toplevel tags, then you'd have to iterate through all the different namespaces. The task here was to optimize creating the datatype cache, and rebuild it during idle time, then use it many times while editing. It may turn out that since there is a local file stream, and a stream of tags from included files that you can remove the sort locally only to solve this problem, since that is the only time it matters. Eric |