Bug 228652 - [formatter] New line inserted while formatting a region of a compilation unit.
Summary: [formatter] New line inserted while formatting a region of a compilation unit.
Status: VERIFIED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.5 M3   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-24 07:35 EDT by Frederic Fusier CLA
Modified: 2008-10-29 05:23 EDT (History)
3 users (show)

See Also:

Attachments
JUnit test case to reproduce the problem (1.50 KB, patch)
2008-04-24 07:35 EDT, Frederic Fusier CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.