Bug 257043

Summary: CodeCompletions implement memberfunction does not work, when header and impl are in different folders.
Product: [Applications] kdevelop Reporter: Sergej Ferlich <monsdar+kde>
Component: Language Support: CPP (old)Assignee: kdevelop-bugs-null
Status: REPORTED ---    
Severity: wishlist CC: aleixpol, max.schwarz, olivier.jg
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: Proposed patch

Description Sergej Ferlich 2010-11-16 07:52:36 UTC 
Version:           unspecified
OS:                Linux

I have a project where the header file is in a different directory than the implementation-file.

-rootDirectory/
---Class.h
---impl/
-----Class.cpp

When I add a method to Class.h, codecompletion does not offer to implement it when I press Ctrl+Space in Class.cpp.

Perhaps it would be better if codecompletion would look into the #includes for not implemented methods.

Note:
Hope the title is speaking, I did not really know how to name this problem.

Reproducible: Always

Steps to Reproduce:
Just create a project with the following structure:
projectDir/Class.h
projectDir/impl/Class.cpp

- Write a simple class in Class.h
- Switch to Class.cpp
- #include "Class.h"
- Press Ctrl+Space to activate CodeCompletion

Actual Results:  
The unimplemented methods of Class.h are not listed

Expected Results:  
Any unimplemented methods of Class.h should be listed. When clicking on it the method-stubs should be added to Class.cpp.

The above case has been experienced with KDevelop 4.1 under Ubuntu 10.04 with Gnome installed. (No specific KDE installed)
Comment 1 Aleix Pol 2013-03-31 01:39:42 UTC 
It's C++ things, so put it under C++
Comment 2 Max Schwarz 2013-04-29 11:58:34 UTC 
*** Bug 319060 has been marked as a duplicate of this bug. ***
Comment 3 Max Schwarz 2013-04-29 12:01:41 UTC 
Created attachment 79544 [details]
Proposed patch

This is still present in git master. Attached is a patch that fixes the problem by disabling the "fast" parameter of CppUtils::sourceOrHeaderCandidate() during the search for the header.

Since the global search for header files is only used as a last resort, I believe it is okay to allow a "slow" search.