CEDET

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

Eric M. Ludlam <eric@...> 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

Hi Eric,

David Engster <deng@...> writes:
> Eric M. Ludlam <eric@...> 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

On Wed, 2009-07-22 at 21:05 +0200, David Engster wrote:
> Hi Eric,
> 
> David Engster <deng@...> writes:
> > Eric M. Ludlam <eric@...> 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