Bug 310391

Summary:	Autocompleting C++ lists unwanted or irrelevant Boost items in all contexts.
Product:	[Applications] kdevelop	Reporter:	Jeremy W. Murphy <jeremy.william.murphy>
Component:	Code completion	Assignee:	kdevelop-bugs-null
Status:	RESOLVED FIXED
Severity:	minor
Priority:	NOR
Version First Reported In:	git master
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:	http://commits.kde.org/kdevelop/035dbfa22e9ceccf91f81671b3d1f08f14932c47	Version Fixed/Implemented In:	5.0.0
Sentry Crash Report:
Attachments:	Unwanted symbols from Boost headers listed first. Autocomplete finds things in Boost headers even though they are not included.

Description Jeremy W. Murphy 2012-11-20 03:41:19 UTC

I expect #include completion to list filenames as appropriate for < or ", but at the moment a few odd things from Boost appear at the top of the list (see the attached screenshot).
They only appear the first time.  If you delete the text after the < or " and start again, they don't appear.  But they will reappear the next time you start a fresh include directive.
It only works for some letters of the alphabet, presumably because there is some single-letter symbol matching it in a Boost header.


Reproducible: Always

Steps to Reproduce:
1. Start a fresh #include directive in a C++ file.
2. See what gets listed if you type a single 'p', 'c' or 'e' after the < or ".

Actual Results:  
Some symbols from Boost headers appear first.


Expected Results:  
Only header files are listed.

Comment 1 Jeremy W. Murphy 2012-11-20 03:42:21 UTC

Created attachment 75372 [details]
Unwanted symbols from Boost headers listed first.

Screenshot of bug.

Comment 2 Milian Wolff 2012-11-21 17:32:32 UTC

Git commit 035dbfa22e9ceccf91f81671b3d1f08f14932c47 by Milian Wolff.
Committed on 21/11/2012 at 18:31.
Pushed by mwolff into branch '4.4'.

Properly set access type if we doIncludeCompletion.

This should fix issues where unrelated include items where shown
when we returned early from the doIncludeCompletion function.

M  +1    -2    languages/cpp/codecompletion/context.cpp

http://commits.kde.org/kdevelop/035dbfa22e9ceccf91f81671b3d1f08f14932c47

Comment 3 Jeremy W. Murphy 2012-11-22 08:08:17 UTC

Bug persists, unfortunately.

I did a little more testing and realized that the same three Boost items appear in any context, not just at a #define.  So if I type "p" in the body of a function, I get the same unhelpful Boost items at the top of the list, every time.  (Which is different to the #define context, where they only appear the first time.)

Comment 4 Jeremy W. Murphy 2012-11-25 01:33:31 UTC

Maybe I tested too early, it's fixed now.  Thanks!

Comment 5 Jeremy W. Murphy 2014-01-05 10:23:07 UTC

Created attachment 84460 [details]
Autocomplete finds things in Boost headers even though they are not included.

Alas, this bug is still around.  As you can see in this attachment, even though the source file is trivial and contains no #include directives, the autocomplete feature suggests things from Boost.

It's worth noting that it almost exclusively suggests things from the Boost Concept Checking Library and the Boost Graph Library.  Occasionally it suggests from the Boost Iterator Library.

Comment 6 Jeremy W. Murphy 2014-01-05 10:28:49 UTC

This bug has returned.  :(  The problem actually extends to autocompletion in any/every situation.

Now one weird thing that I have noticed is that it sometimes it goes away!  That is, after repeated occurrences of suggesting things from Boost, suddenly it won't suggest anything from Boost for the same completion.  But I cannot predict it yet, which is obviously very frustrating, but I tell you so that you know weird things are afoot.  Cheers.

Comment 7 Jeremy W. Murphy 2014-01-26 07:38:47 UTC

I'm interested in helping fix this.  The annoyance is motivating me.  :)

If I want to debug and step through the code that adds things to the completion list, should I just focus on languages/cpp/codecompletion/context.cpp?  Anywhere else I should look?

Comment 8 Milian Wolff 2014-01-27 11:52:38 UTC

If I understand correctly, the things that bug you are the items which want to add missing includes, right? If so, look at missingIncludeCompletionItems in missingincludeitem.cpp. Otherwise context.cpp is the way to go.

Good luck!

Comment 9 Kevin Funk 2016-09-08 20:16:47 UTC

Hello!

We are working on a new clang-based C/C++ language plugin for KDevelop 5 which
supersedes the old C++ plugin in KDevelop 4. See e.g.:
https://www.kdevelop.org/news/first-beta-release-kdevelop-500-available

Due to a lack of manpower, we cannot fix bugs in the old C++ plugin. We rather
want to supply a good Clang based C++ experience for KDevelop 5 than wasting
our time on the legacy C++ support for KDevelop 4.

With the new clang-based C/C++ language plugin, the bug presented here does not
occur. In my testing. For these reasons, I'll close this bug. Please stay tuned
for KDevelop 5.

If you think this bug is applicable to Clang/KDevelop 5, please reopen the
report and add new information on how to reproduce the bug there.

Comment 10 Jeremy W. Murphy 2016-09-10 00:41:25 UTC

Haha, I had forgotten all about this bug. I'm not sure if it even still occurs in the 4.x series but it's certainly not in 5.x. I'll have a look later out of curiosity as I still have one machine running KDE4.