Bugzilla – Full Text Bug Listing
| Summary: | [formatter] new failures in last 2 nightly builds | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Olivier Thomann <Olivier_Thomann> | ||||
| Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | daniel_megert, satyam.kandula | ||||
| Version: | 3.5 | ||||||
| Target Milestone: | 3.6 M2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
This is a consequence of fix for bug 286912. The problem is in method Scribe.getCurrentIndentation(int), which behaves differently when line ends is only one character as in Linux. I copied it from getCurrentCommentOffset(int), but it seems that the binary search does not give correct results when the start position matches a line end... I'll continue my investigation deeper tomorrow and currently disable the offending test... Created attachment 145466 [details]
Proposed patch
The usage of the binary search method in getCurrentCommentOffset(int) method was correct as the start position is never supposed matching and line end. In getCurrentIndentation(int) it's possible, hence the return value must be tested and replaced accordingly if it's negative...
Note that the test also needed to be changed as the indentation delta for each broken line is kept and was only 4 characters...
Released for 3.6M2 in HEAD stream. Verified for 3.6M2 using I20090914-1800 Verified. |
Recent nightly builds show a failure in the formatter tests. > org.eclipse.jdt.core.tests.model_linux.gtk.x86 > org.eclipse.jdt.core.tests.model_linux.gtk.x86_6.0 > org.eclipse.jdt.core.tests.model_macosx.cocoa.x86_5.0 The failure is located in: org.eclipse.jdt.core.tests.formatter.FormatterRegressionTests.testBug201022