Bug 202390

Summary: Assistant offers to declare a member function instead of variable
Product: [Applications] kdevelop Reporter: Alexander <ashaduri>
Component: Language Support: CPP (old)Assignee: kdevelop-bugs-null
Status: CONFIRMED ---    
Severity: normal CC: aleixpol, cponnapalli
Priority: NOR    
Version First Reported In: git master   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: kdevelop Assistant offers to declare the invalid member identifier with the correct structure types

Description Alexander 2009-08-03 15:00:54 UTC
Version:           SVN (using KDE 4.2.4)
Compiler:          gcc 4.3.2 
OS:                Linux
Installed from:    SuSE RPMs

Consider the following code:

class A {

	void f() {
		member->something();
	}

};

The "member" word is correctly highlighted as invalid. If I move the cursor there, the Assistant pops up, suggesting:
(1) Declare void A::member()
(2) Declare private void A::member()
(0) Hide

Of course, declaring "member" as a member function is not the right thing to do (even though the error highlight goes away). It should detect whether it's called as member-> or member(...)->, and offer to declare the member functions only in the second case.
Comment 1 Aleix Pol 2013-02-28 00:34:32 UTC
Still happens, probably shouldn't offer anything...
Comment 2 chaitanya srinivas ponnapalli 2016-04-30 06:22:16 UTC
Created attachment 98696 [details]
kdevelop Assistant offers to declare the invalid member identifier with the correct structure types

Reproduced the code given above containing the invalid variable member.
Kdevelop assistant correctly highlights as an invalid identifier. However, it does NOT suggest either of the following fixes:
(1) Declare void A::member()
(2) Declare private void A::member()

kdevelop rightly suggest that the invalid identifier 'member' should be declared either as a class or a struct. So, its working fine.
Comment 3 Kevin Funk 2016-05-01 09:07:09 UTC
Still a problem. KDevelop shouldn't even propose forward-declaring it -- it wouldn't make the example code valid either (`member` is dereferenced, thus the declaration needs to be visible).