> Sami>  @@ -800,21 +800,27 @@ make_symbol_overload_list_using (const char *func_name,
> Sami>   				const char *namespace)
> [...]
> Sami>  -  for (current = block_using (get_selected_block (0));
> Sami>  -       current != NULL;
> Sami>  -       current = current->next)
> Sami>  -    {
> Sami>  -      if (strcmp (namespace, current->import_dest) == 0)
> Sami>  -	{
> Sami>  -	  make_symbol_overload_list_using (func_name,
> Sami>  -					   current->import_src);
> Sami>  -	}
> Sami>  -    }
> Sami>  +  for (block = get_selected_block (0);
> Sami>  +       block != NULL;
> Sami>  +       block = BLOCK_SUPERBLOCK(block))
> Sami>  +    for (current = block_using (block);
> Sami>  +	current != NULL;
> Sami>  +	current = current->next)
> Sami>  +      {
> [...]
>
> This part seems a little weird to me.
> make_symbol_overload_list_using calls make_symbol_overload_list_namespace,
> which calls make_symbol_overload_list_qualified, which itself
> starts with get_selected_block and iterates over the superblocks.
>
> It seems to me that only one such iteration should be needed.
> I don't have a test case but it seems like this could cause incorrect
> results in some corner case.
>

It is weird but it is due to the nature of the symbol tables. The first 
iteration, by make_symbol_overload_list_using, is iteration over the 
blocks' import statements. The Second iteration is actually searching 
for the symbol.

If we assume that names belonging to namespaces can only be in the 
static scope -since namespace symbols are flattened to the nearest 
parent- then we can separate the qualified and unqualified searches
and eliminate the nesting of the iterations.

Please see patch 2/2.

> Sami>  +# some unary operators for good measure
> Sami>  +# Cannot resolve function operator++ to any overloaded instance
> Sami>  +gdb_test "p ++q" "= 30"
>
> It would be interesting to know if "q++" would call an overloaded
> postfix operator++.  These have a hack in the C++ spec to differentiate
> them from prefix ++.
>

It does work. This is tested in userdef.exp.

> I'm also curious to know if "ADL avoidance" works properly when a
> qualified reference to "operator<whatever>" is used.  I didn't see a
> test for that in this patch.  (If there is already one in the test
> suite, then of course we don't need a new one...)
>

Yes it does. I have added a test case.