Bug 298511 - Change returned type of static function in it's definition (cpp file) made remove word "static" in it's declaration (header)
Summary: Change returned type of static function in it's definition (cpp file) made re...
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: Language Support: CPP (Clang-based) (show other bugs)
Version: 4.90.91
Platform: Kubuntu Linux
: VHI normal
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2012-04-20 22:32 UTC by Piotr Mierzwinski
Modified: 2017-11-28 21:32 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Mierzwinski 2012-04-20 22:32:44 UTC
Change returned type (example from int to char) of static function in it's definition made shows menu: "1 - Update declaration signature". After choose Alt+1 word "static" is removed in it's declaration. Example:
header file:
#ifndef TEST_H
#define TEST_H

class Test
{
public:
	Test();

	static int foo( int param );
};

#endif // TEST_H

cpp file:
#include "test.h"

Test::Test()
{
}

int Test::foo(int param)
{
	return 1;
}

Now let's change return type int to char.

Reproducible: Always

Steps to Reproduce:
1. Create class Test
2. In header's file (section public) create declaration of static function (example: "static int foo( int param );") 
3. In cpp file create definition for this function (example: "int Test::foo(int param) { return 1; }")
4. Save all files
5. Change retuned type from int to char
6. Choose Alt+1 for popup menu: "1 - Update declaration signature  0 - Hide"
7. Look to the header file
Actual Results:  
header file:
#ifndef TEST_H
#define TEST_H

class Test
{
public:
	Test();

	   char foo( int param );
};

#endif // TEST_H

cpp file:
#include "test.h"

Test::Test()
{
}

char Test::foo(int param)
{
	return 1;
}


Expected Results:  
header file:
#ifndef TEST_H
#define TEST_H

class Test
{
public:
	Test();

	static char foo( int param );
};

#endif // TEST_H

cpp file:
#include "test.h"

Test::Test()
{
}

char Test::foo(int param)
{
	return 1;
}


Tested on KDevelop4.3.1
Linux distribution: Mandriva 2011.0
Comment 1 Aleix Pol 2013-03-31 01:40:01 UTC
It's C++ things, so put it under C++
Comment 2 Piotr Mierzwinski 2013-04-01 20:34:18 UTC
I don't understand. I choose component related with C++ (Language Support: CPP)
Comment 3 Piotr Mierzwinski 2016-01-30 22:58:48 UTC
In KDevelop 5.0 (beta2) it doesn't work at all :-(.

When I try to change returned type being in definition then nothing happen.
When I try to change returned type being in declaration then I'm getting "Update definition signature" pop up, so I choose 1 (Alt+1) and nothing happen, and "Update definition signature" still hangs on the screen.

KDevelop, KDevplatform cloned at 30.12.2016 (at evening) from 5.0 branch.
Comment 4 Kevin Funk 2016-02-03 00:24:12 UTC
@Piotr: It works for me using latest 5.0 branch. Are you sure?

This should be fixed by:

commit d332c3af3168cb3499674642d7884395e6db54f1
Author: Milian Wolff <mail@milianw.de>
Date:   Wed Dec 2 13:14:14 2015 +0100

    Keep static modifier of class functions if we adapt the signature.
    
    BUG: 356179
Comment 5 Kevin Funk 2016-02-03 00:25:31 UTC
Why do we have two bug reports for this to begin with? Marking as duplicate. Please report on that one.

*** This bug has been marked as a duplicate of bug 356179 ***
Comment 6 Piotr Mierzwinski 2016-02-06 21:55:27 UTC
[Kevin] @Piotr: It works for me using latest 5.0 branch. Are you sure?
I've retested it again using kdevelop-4.90.91 built by packager from Mageia Cauldron distribution.
I can say that change of returned type of static function made in header file works (cpp file is properly updated).

Only left minor bug(s).
After click in "1" on "Adapt signature" window/toolTip, this window still visible on the screen and I expect that disappear. It doesn't happen when I press shortcut "Alt+1" ("Adapt signature" disappear).
Second issue is that, in cpp definition noting happen after changing return type.

[Kevin] Why do we have two bug reports for this to begin with? Marking as duplicate. Please report on that one.
For me it was two things, because involved two behaviours (actions made by user to get an error).
In bug 356179 "static" word was removed after removing last parameter in the function/method (which was declared static). And here definition/declaration is not updated after changing the type.
Comment 7 Piotr Mierzwinski 2016-02-06 22:04:12 UTC
And about current (today [06.02.2016] evening [after 10pm] cloned source from origin/5.0 branch) version.
I retested it and here noting changed comparing to issue sent in the post made at "2016-01-30 23:58:48 CET", so definition/declaration is not updated. I'm not sure where is the issue :/.
Comment 8 Milian Wolff 2016-02-07 15:13:42 UTC
I just tested it, and this case seems to be completely broken now.
Comment 9 Milian Wolff 2016-05-24 21:03:03 UTC
Git commit b37f668452c3727b6a9835096d1a11f74bdb8e54 by Milian Wolff.
Committed on 24/05/2016 at 21:02.
Pushed by mwolff into branch '5.0'.

Keep contexts alive when referenced by a problem.

This fixes the signature assistant when invoked from the header.
Now that we update the .cpp file when the header is changed, we
lost the declarations therein if e.g. the function return type got
changed. That then leads to issues in the signature assistant which
relies on the DUChain data.

I wonder whether we can find a more reliable way to store this data
to remove such kind of hacks... Problably we will have to work with
upstream clang and add FixIts for the signature assistant there
somehow...
Related: bug 358479

Differential Revision: https://phabricator.kde.org/D1140

M  +4    -0    languages/clang/codegen/adaptsignatureassistant.cpp
M  +37   -7    languages/clang/duchain/builder.cpp
M  +15   -0    languages/clang/tests/test_assistants.cpp

http://commits.kde.org/kdevelop/b37f668452c3727b6a9835096d1a11f74bdb8e54
Comment 10 Nate Graham 2017-11-28 21:32:20 UTC
Marking as resolved per last comment that indicates a commit to resolve the issue. If this is still reproducible, please leave a comment.