Auto-correction will sometimes incorrectly change a dot to an arrow. To reproduce, start with the following code, and save it to a .c file. struct foo { int x; }; void func (void) { } Once it's saved, type the following into the body of the function (type everything): struct foo f; // wait some time for the parser here &f.x; While typing the second statement, "." is changed to "->" as it is typed, even though the former is valid C code, and the auto-corrected version is invalid (type error because "&f->x" is parsed as "&(f->x)"). Note that this bug doesn't happen every time. Some editing, saving and waiting may be required to reproduce it. Reproducible: Sometimes
The dual case is also broken! struct bar { int* y; }; void func (void) { bar* b = new bar; *b-> } While typing the second statement, "->" is changed to "." as it is typed. As above, the former is valid C code, and the auto-corrected version is invalid.
I can reproduce this in KDevelop 4.5.1 on Gentoo with KDE SC 4.11.2.
A first problem, IMHO, is located in CodeCompletionContext:: CodeCompletionContext() function, context.cpp:470. The code: m_accessType = findAccessType( accessStr ); if ( m_depth > 0 || !PARENT_ACCESS_STRINGS.contains( accessStr ) ) m_text.chop( accessStr.length() ); removes the '->' or '.' at the end of the current C++ code too early, as '->' and '.' operators have precedece over "*' and '&'. So, as first, the above code should be replaced by: m_accessType = findAccessType( accessStr ); if ( m_depth > 0 || (!PARENT_ACCESS_STRINGS.contains( accessStr ) && !MEMBER_ACCESS_STRINGS.contains( accessStr )) ) m_text.chop( accessStr.length() ); Second issue: CodeCompletionContext:: findExpressionAndPrefix(), context.cpp:950 don't prepend reference and dereference operators to expression if current access type involves operators which have precedence over '*' and '&', that is '->', '.' and '::' In short, if (op == "*" || op == "&") { expression.prepend(op); expressionPrefix.chop(op.length()); } should be replaced by if ((op == "*" || op == "&") && m_accessType != ArrowMemberAccess && m_accessType != MemberAccess && m_accessType != StaticMemberChoose && m_accessType != MemberChoose) { expression.prepend(op); expressionPrefix.chop(op.length()); } this should fix the issue.
Hey, thanks for the analysis. Could you create a patch and upload it on reviewboard.kde.org? Then we could get this integrated asap. Thanks
Gabriele, any progress with comment #4?
A patch is available on Review Board, but it breaks a few of the code completion testing routines, I shared it with you too.
*** Bug 330500 has been marked as a duplicate of this bug. ***
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Yes, the reported, incorrect, behaviour is fixed, now. Sorry for not reporting early.