Version: (using KDE KDE 3.5.5) Installed from: Ubuntu Packages Compiler: gcc 4.1 OS: Linux I compiled Kdevelop from SVN at 11.01.2007 as described by http://www.kdevelop.org/index.html?filename=3.4/branches_compiling.html on my Kubuntu Edgy (10/2006) box. Code completion works now mostly very good. The code completion has still a problem to propose a function, that is declared inside a: #ifdef ... ... #else ... #endif block. The corresponding header IS parsed, as other pieces of that header ARE proposed as awaited. The interesting fact: I created also a CTAGS tags file. That function is proposed by the ctags-plugin window, if I type the first characters of its name. So I'm wondering, why the code completion does _not_ incorporate a configured tags file as second source for code completion. Or is it possible, that I have to change some KDevelop global or project specific settings? But the tags file seems to be not so bad, as the ctags-plugin proposes the items as wanted -> simply the editor component is not presenting the same level of knowledge. Some important information on my project setting: + the project files are in a subdirectory like IsoAgLib/compilerProjects/proj1 --> the file proj1.kdevelop.filelist uses relative paths with some "../" at beginning (works fine for class browser) + most source files are placed in IsoAgLib/xgpl_src + the tag file has been manually created as IsoAgLib/tags with exurbant-ctags + the tags file in IsoAgLib/tags is referred by absolute path name in kdevelop project file which works at least fine for lookup in the plugin-subwindow of ctags The header file is structured as follows: namespace IsoAgLib { class iISOMonitor_c : private __IsoAgLib::ISOMonitor_c { public: /** initialisation for ISOMonitor_c which can store optional pointer to central Scheduler_c instance */ void init( void ) { ISOMonitor_c::init(); } //.... }; #if defined( PRT_INSTANCE_CNT ) && ( PRT_INSTANCE_CNT > 1 ) /** C-style function, to get access to the unique ISOMonitor_c singleton instance * if more than one CAN BUS is used for IsoAgLib, an index must be given to select the wanted BUS */ inline iISOMonitor_c& getIisoMonitorInstance( uint8_t rui8_instance = 0 ) { return static_cast<iISOMonitor_c&>(__IsoAgLib::getIsoMonitorInstance(rui8_instance));} #else /** C-style function, to get access to the unique ISOMonitor_c singleton instance */ inline iISOMonitor_c& getIisoMonitorInstance( void ) { return static_cast<iISOMonitor_c&>(__IsoAgLib::getIsoMonitorInstance());} #endif } ==>> Completion WORKS in following scenario: IsoAgLib::iISOMonitor_c. <<---big list of all awaited member function is presented with nicely formatted documentation on each function Completion DOES NOT work in: IsoAgLib::getIsoM <<--- there is no popup window which would suggest me completions for both or one of the declared variants of getIisoMonitorInstance(). The ctags engine of the ctags-plugin subwindow proposes me simply _both_ versions of getIisoMonitorInstance( uint8_t rui8_instance = 0 ) and getIisoMonitorInstance( void ). What could I do, to get the same level of CTAGS auto-completion support in the editor component as is presented in the ctags plugin subwindow? Thanks, Achim
I tried with your example and I had no problems getting completion for the #else part of the #if. Of course kdevelop doesn't know the result of evaluating the condition so it always offers the else part only, but it works here. Unless somebody else can reproduce this we can't help you Using the ctags plugin is not possible because its a plugin. It may be disabled and it also has no API to be able to extract information from it. Furthermore the base for the code-completion is a code model structure which is the same for all languages kdevelop supports. Apart from the fact that the code you present doesn't make the slightest sense, you don't need the ifdef there. But I guess you have actually more things inside it than just the things you present.
The parser needs to resolve the macro in order to understand how to parse the file. I believe we've delt with this problem as much as we reasonably can in KDevelop3. See comment #3 in bug #132643. *** This bug has been marked as a duplicate of 132643 ***
Nice that it works for you - but it does not work here. So I'd like to trace this down to the real problem reason with your help. Maybe of interest: a) the whole header is enclosed in a block of: #ifndef IISO_MONITOR_H #define IISO_MONITOR_H //<class declaration + global funcs> ##endif --> should be no problem, as parsing of contained class works b) as soon as the complete function name "getIisoMonitorInstance" is typed , the further features of auto-complete are working as expected: 1) adding a "(" resulting in "getIisoMonitorInstance(" delivers me a nice pop up, where the auto-complete database presents me the comment line of the declaration block of the corresponding function 2) adding a further ")" resulting in "getIisoMonitorInstance()." delivers me a nice long pop up list with all member functions of the returned class ==>> The parsing engine interpretes the code correctly! But something disturbes the auto-complete feature, so that it doesn't suggest me any possible completion. Is it possible that any of the kdevelop-plugins like abbreviation or any of the kdevelop-editor-plugins like "KTextEditor-Plugin für Wortergänzungen" ("KTextEditor-Plugin for word completion") or "KTextEditor-Plugin zur einengenden Suche" ("KTextEditor-Plugin for limiting search") does disturb the completion of function names when just a part of the function name has been typed? I hope, that this more detailed description helps you/us to trace the problem down. Is there any plugin that _might_ cause problems, so that I should deactivate it? What can block the auto-completion from suggesting me function names, that match to a partially typed function name - when the DB _knows_ the function as soon as I have typed the full name of the function? Thanks, Achim
Do you get any completion at just "IsoAgLib::" ? (Ignore my comment #2 for the moment.. this might not be the macro problem at all.)
Yes. And now I've found the problem reasons: 1) I wrongly added the same sources twice for parsing: + as persistent class storage in "Code Completion Databases" + through the proj.kdevelop.filelist --> as soon as I remove the corresponding "Code Completion Database", the problem vanishes --> I think that this should NOT happen --> see the other problem reason I outline below ==> this setup might be the reason, that you were not able to reproduce my problem 2) as soon as source code is basically known by persistent class storage in "Code Completion Database", a GLOBAL INLINE function in a header causes trouble. When I change the function to a pure DECLARATION as: /** comment */ iISOMonitor_c& getIisoMonitorInstance( uint8_t rui8_instance = 0 ); --> this function gets presented as a global function even through "Code Completion Database" with persistent class storage feature But as soon as I change it back to /** comment */ inline iISOMonitor_c& getIisoMonitorInstance( uint8_t rui8_instance = 0 ) {}; --> the global function vanishes from auto-completion from code completion DB (but is still accessible as soon as I type "(" after the full function name) ==>> The C++ syntax correct global inline function inside a header causes the parsing engine to not find the corresponding function name for auto-complete - until the full function name is known. I assume, that the finalizing "(" after the function name causes a deeper search in the code completion DB, which does _then_ reveal the known information about this item. The #ifdef ... #else ..... #endif thing does NOT cause any change of my observed behaviour. So somebody should change the error subject to "global inline functions in header disturb auto-completion" . ==>> even if my doube insertion of some modules might make things difficult for the engine, the parsing engine for persistent class storage for code completion DB should be working identically as the parsing engine for files which are listed by proj.kdevelop.filelist Hope this information helps to solve the problem in the persistent class storage parsing, Achim
Intriguing.. it does indeed look like completion works slightly different from the catalog (the database based CC) and from the codemodel (in memory representation of the current project) The latter appears to handle namespace::cla| completion, while the former does not (it only manages namespace::|).
this is a C++ problem in kdevelop4 I think.
Should work in KDev4, and KDev3.4 is not worked on any more.