Bug 150558 - Moving field/method to another class causes loss of following comment
Summary: Moving field/method to another class causes loss of following comment
Status: ASSIGNED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.8   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
: 151476 258377 264941 404856 (view as bug list)
Depends on: 46171
Blocks:
  Show dependency tree
 
Reported: 2006-07-13 15:19 EDT by Luke Hutchison CLA
Modified: 2023-02-25 13:05 EST (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Hutchison CLA 2006-07-13 15:19:44 EDT
Given the following class, if the cursor is placed in the "MISSING_DATA" symbol and then Refactor->Move is selected, and another class in the same package is chosen as the destination, both the comment before and after the declaration are selected, but only the comment before actually gets moved.  The comment after the declaration (with all the equals signs) disappears.


public class Main {

	// Should be the same as the number of processors in the machine
	public static final int NUM_THREADS = 4;

	// Used internally to represent missing data
	public static final int MISSING_DATA = Integer.MIN_VALUE;

	// ===============================================================================================================================

	/**
	 * Run the Analyzer class on each pair of samples, collecting the results in a ResultAccumulator. Works in parallel across NUM_THREADS threads.
	 * 
	 * @param locOffset
	 * 
	 * @return Returns the results of the all-pairs comparison using the specified loci.
	 */

	public ResultAccumulator analyzeLocusPair() { /*...*/
	}
}
Comment 1 Luke Hutchison CLA 2006-07-13 15:21:01 EDT
Again, without line-wrapping probs:


public class Main {

        // Should be the same as the number of processors in the machine
        public static final int NUM_THREADS = 4;

        // Used internally to represent missing data
        public static final int MISSING_DATA = Integer.MIN_VALUE;

        // =================================================================

        /**
         * Run the Analyzer class on each pair of samples, collecting the...
         * 
         * @param locOffset
         * 
         * @return Returns the results of the all-pairs comparison using the...
         */

        public ResultAccumulator analyzeLocusPair() { /*...*/
        }
}

Comment 2 Martin Aeschlimann CLA 2006-07-18 06:42:08 EDT
Yes, sorry, thats heuristic of the AST rewriter. We associate all comments that are directly above or below an element. As the element is removed, we also have to remove the following separator, otherwise separators would add up.

Unhappy in the current scenarioo, but very hard to solve for all cases.

No action planed.
Comment 3 Martin Aeschlimann CLA 2006-07-27 05:01:18 EDT
*** Bug 151476 has been marked as a duplicate of this bug. ***
Comment 4 Dani Megert CLA 2008-12-11 03:52:03 EST
*** Bug 258377 has been marked as a duplicate of this bug. ***
Comment 5 Dani Megert CLA 2009-02-16 03:22:41 EST
*** Bug 264941 has been marked as a duplicate of this bug. ***
Comment 6 Dani Megert CLA 2013-04-04 04:27:28 EDT
*** Bug 404856 has been marked as a duplicate of this bug. ***
Comment 7 Markus Keller CLA 2013-04-04 07:37:05 EDT
Comment 2 is wrong. There's no reason why a move refactoring should drop comments. Either they stay at the old location or they move with the method.
Comment 8 Luke Hutchison CLA 2018-09-14 05:24:18 EDT
Still a problem 12 years later. Refactoring should never drop comments.

Here's a minimal testcase:


// BEFORE:

public class MoveFieldBug {
    public static class Class1 {
        // Comment before
        int field;
        // Comment after
    }
    
    public static class Class2 {
    }
}


// AFTER: (Right-click "field", then choose Refactor > Move > Class2)

public class MoveFieldBug {
    public static class Class1 {
    }
    
    public static class Class2 {

        // Comment before
        int field;
    }
}
Comment 9 Noopur Gupta CLA 2018-09-14 06:27:08 EDT
It's an issue with ASTRewrite source ranges. See bug 46171 and bug 250142 for similar cases.
Comment 10 Eclipse Genie CLA 2020-09-04 14:33:16 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 11 Jeff Johnston CLA 2020-09-08 19:53:26 EDT
This still occurs for 4.17.
Comment 12 Eclipse Genie CLA 2023-02-25 13:05:13 EST
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.