https://bugs.kde.org/show_bug.cgi?id=468605
--- Comment #3 from Igor Kushnir <igor...@gmail.com> --- (In reply to Alessandro Carinelli from comment #2) > Checking that m_results->Numresults is also different from 1 on line 984 > seems to fix the issue but I have no idea about what this variable > represents and I found no comments about it so I don't know if this breaks > anything else. Starting at the line 966 of the file plugins/clang/codecompletion/context.cpp, KDevelop takes a code fragment that leads up to and includes '.' (stored in the variable trimmedText); temporarily replaces this last dot with '->'; and then asks libclang to try and come up with possible completions after that arrow. If libclang finds a way to complete the arrow (NumResults [= the number of completion results] is positive), KDevelop assumes that the code with the arrow would compile given some more typing or completion after the arrow, decides that the dot should indeed be replaced with an arrow and does just that. So no, checking that m_results->Numresults is also different from 1 does not seem to be a good idea, at least not on the surface. You could check what is that strange completion result that libclang finds after "2." and see if this completion is something KDevelop should ignore here. You can start with debug-printing (via e.g. qCritical()) str.c_str(). The string is clearly not equal to "Parse Issue", but maybe it is something else, which should also be ignored. -- You are receiving this mail because: You are watching all bug changes.
