Bug 228652

Summary: [formatter] New line inserted while formatting a region of a compilation unit.
Product: [Eclipse Project] JDT Reporter: Frederic Fusier <frederic_fusier>
Component: CoreAssignee: Frederic Fusier <frederic_fusier>
Status: VERIFIED WORKSFORME QA Contact:
Severity: normal    
Priority: P3 CC: benno.baumgartner, daniel_megert, Olivier_Thomann
Version: 3.4   
Target Milestone: 3.5 M3   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
JUnit test case to reproduce the problem none

Description Frederic Fusier CLA 2008-04-24 07:35:27 EDT 
Created attachment 97436 [details]
JUnit test case to reproduce the problem

This issue has been discovered while activating new comment formatter (see bug 102780 and bug 227043) on clean-up action but in fact already exists in 3.3.

The new line is not inserted while formatting the compilation unit through the menu item or using Ctrl-Shift-F, but only using the CodeFormatter.format(int, String, int, int, int, String ) method with kind = K_COMPILATION_UNIT with an offset and a length.

Attached the JUnit test case to reproduce the problem...
Comment 1 Frederic Fusier CLA 2008-04-24 07:38:29 EDT 
The problem is in Scribe.isValidEdit(int) method. When the position is not in the covered region, then the edit is wrongly modified at line 943:

if (i - editOffset != editReplacementLength && i != editOffset + editLength - 1) {
	edit.offset = starting.getOffset();
	edit.length = 0;
	edit.replacement = edit.replacement.substring(i - editOffset);
	return true;
}

This if block definitely looks suspiciousn, especially start position and length... Comment it fixes the problem but I'll see if I can write a smarter fix.
Comment 2 Frederic Fusier CLA 2008-04-24 10:05:21 EDT 
The is a side effect of bug 49817. The fix of that bug does not seem related to the original issue, so we need to investigate whether that fix can be removed or not...

Olivier, what is your mind about this?
Comment 3 Frederic Fusier CLA 2008-09-22 11:00:32 EDT 
Close as worksforme because I cannot reproduce using 3.5M2. My assumption is that the problem vanished when bug 234583 has been fixed. Edits are now split hence the condition of the offending if should not be true anymore...
Comment 4 Jerome Lanneluc CLA 2008-10-29 05:23:17 EDT 
The test case from comment 0 still fails for me but for another reason (see bug 252556). However a new line is not inserted, so marking as verified for 3.5M3 using I20081027-1800.