BUG: Extract method refactoring breaks existing code

Hi,

Extract method refactoring produces wrong code in case of out parameters.
Minimum test case:

Source code:
public void Test(out decimal result)
{
result = 3*2; // chose extract method on this line
}

Resulting code:
public void Test(out decimal result)
{
Set();
}

private static void Set()
{
decimal result;
result = 3 * 2; // chose extract method on this line
}


So refactoring produces code which doesn't compile and breaks program logic.

Resharper build 376

WBR, Igor


3 comments
Comment actions Permalink

In the extract method dialog in build 448, you can choose either to return the result, or change the return to none, which makes it an out parameter. It probably is a bug fixed in 3.0 that won't make it back to 2.5 (my guess)

There are 4 other nightly builds you could look through (up to build 380) to see if its fixed ( but I don't think they really have fixed anything since 2.5.2 RC2 )

http://www.jetbrains.net/confluence/display/ReSharper/ReSharper2.5Nightly+Builds

0
Comment actions Permalink

Infact, as I suspected:

http://www.jetbrains.net/jira/browse/RSRP-25886

It was fixed in Build 430.

0
Comment actions Permalink

Hello Chadwick,

That's true: in 3.0 we have rewritten extract method from the ground up
so most fixes won't make it to older releases.

Oleg Stepanov
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

In the extract method dialog in build 448, you can choose either to
return the result, or change the return to none, which makes it an out
parameter. It probably is a bug fixed in 3.0 that won't make it back
to 2.5 (my guess)

There are 4 other nightly builds you could look through (up to build
380) to see if its fixed ( but I don't think they really have fixed
anything since 2.5.2 RC2 )

http://www.jetbrains.net/confluence/display/ReSharper/ReSharper2.5Ni
ghtly+Builds



0

Please sign in to leave a comment.