Bug 58502

*** Bug 58503 has been marked as a duplicate of this bug. ***

I can confirm that this problem still exists (using KDevelop 3.0.0b1).
If a class is defined in a namespace and then used in another file, code completion will not work on the defined instance. For example:

  using namespace MYNAMESPACE
  MYCLASS instance;

Here, code completion on 'instance' will not work.
If however i do the following:

  MYNAMESPACE::MYCLASS instance;

Here code completion on 'instance' will work as expected.

Kdevelop 3.0beta1 doesn't handles "using namespace" correctly.

a) When the project defines two or more classes with the same name in different namespaces, kdevelop completes from  a randomly chosen class that match the class name, whenever its namespace is in use or not (with "use namespace XXX;").

For example:

namespace test1 { class test; };
namespace test2 { class test; };
using namespace test2;
test t; // t is wrongly parsed as an instance of test1::test

b) When a class is loaded from a persistant store, kdevelop only check it if you  write the complete namespace before the class name. 

For example, this works:
  #include <list>
  std::list<int> l; // l is correctly parsed as an instance of std::list
but this doesn't:
  #include <list>
  using namespace std;
  list<int> l; // Kdevelop doesn't find the class of l

I was going to start a new whishlist item, but it would have addressed this issue as a subset, so I'm going to post my thoughts here. This may be too resource intensive to implement, but I believe the idea is worth considering. I propose the code completion database be parsed by antlr (or whateve the proper tool would be) and stored in a tree(?) form representative of the visibility structure of the libraries.  Currently I can begin typing QSt and I get code completion for all the Qt classes that share this initial segment.  We need a mechanism for determining the location in the library database tree corresponding to the current scope of the program. and only used descendents of that location to populate the code completion list.

This approach could be used for #include control lines as well.  It may prove more difficult, but I believe the header files could be queried to determine their namespace scoping, and included in the data structure at a location subordinate to the header file containing the namespace declaration.

While looking over the gcc documentation, I found specifications of where gcc looks for headers.  Those specifications could be used to determine the correct subset of the database.  It seems reasonable that much of the building of the tree could be cached. It might be reasonable to store a separate cache per library, or namespace.  This would probably be best accomplished by storing the cache local to the user's KDevelop configuration, rather than in the libraries directory structure.  It may even be possible to distribute pre-construct cache files (or perhas the should be called mapping file in such a case.)

Since there already is a code completion database, it seems reasonable to start by examining how it might be used to implement this design.  I guess this design would also entail parsing the source code on the fly, and building a designtime translation unit.

These look like good jumping off points to find out who to interpret project settings and environment variable in order to implement the design.

http://gcc.gnu.org/onlinedocs/gcc-3.3.2/gcc/Invoking-G--.html
http://gcc.gnu.org/onlinedocs/gcc-3.3.2/gcc/Environment-Variables.html

BTW, I can talk the talk, but I am not that skilled of a (C++) coder, so, until those skills are significantly improved, I won't be the one writing the code.

The following completes as of 2005-03-08;

namespace Baz
{
	class TestClass : public QWidget
	{
		Q_OBJECT
	public:
		TestClass( QWidget *parent = 0, const char *name = 0 );
	
		~TestClass();
	
	private:
		TestClass *m_class;
	};
}

using namespace Baz;

void TestClass::someMethod()
{
	m_class-> //compete box appears with inherited methods from QWidget
}

I'm marking as can not confirm, but feel free to present an _actual_ test case that doesn't work if you can find one.