Bug 58502 - code completion doesn't work with namespace
Summary: code completion doesn't work with namespace
Status: RESOLVED WORKSFORME
Alias: None
Product: kdevelop
Classification: Applications
Component: Code completion (show other bugs)
Version: 3.0.0a4
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KDevelop Developers
URL:
Keywords:
: 58503 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-05-15 01:04 UTC by Sylvain Pointeau
Modified: 2005-03-08 23:50 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sylvain Pointeau 2003-05-15 01:04:25 UTC
Version:           3.0 alpha 4 (using KDE KDE 3.1)
Installed from:    Compiled From Sources
OS:          Linux

The code completion works very well but only for the class declared outside a namespace.
An another request is that the files into a sub directory should be parsed for code completion.
For instance I am obliged to declare each sub includepath into the qt project (.pro).

Thanks a lot for your feedback & kind regards
Comment 1 Jens Dagerbo 2003-05-15 01:18:23 UTC
*** Bug 58503 has been marked as a duplicate of this bug. ***
Comment 2 Mark Kremers 2003-10-29 11:07:19 UTC
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.
Comment 3 Unai Uribarri 2003-11-30 02:24:47 UTC
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
Comment 4 Steven T. Hatton 2004-02-24 09:52:42 UTC
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.
Comment 5 Adam Treat 2005-03-08 23:50:07 UTC
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.