Community
Participate
Working Groups
Follow-up of bug 286601, and more generally speaking since massive tests exist, the formatter is still instable (i.e. files having different formatting output while repeating it twice) in certain circumstances. Typically tests done while testing fixes for bug 286601 showed that there are several noticed instabilities while running the formatter massive tests on the 3 existing full source workspaces (Eclipse 3.0, Galileo and JDKs). Here are the numbers for the v_A16 version: 1) using the Eclipse built-in profile: a) Eclipse 3.0 wksp - 1 file has no output while formatting! - 8 files have different output while reformatting twice but was expected! - 714 files have different output while reformatting twice but only by leading white spaces! - 7 files have different output while reformatting twice but only by white spaces! b) Galileo wksp - 3 files have no output while formatting! - 47 files have different output while reformatting twice! - 2 files have different output while reformatting twice but was expected! - 2384 files have different output while reformatting twice but only by leading white spaces! - 14 files have different output while reformatting twice but only by white spaces! c) JDKs wksp - 4 files have unexpected failure while formatting! - 1 file has no output while formatting! - 115 files have different output while reformatting twice! - 1148 files have different output while reformatting twice but only by leading white spaces! - 43 files have different output while reformatting twice but only by white spaces! 2) using a typical profile built from the one provided in bug 286601, ie. profile = Eclipse built-in + Brace on next line for all positions + Never join lines for Line wrapping a) Eclipse 3.0 wksp - 1 file has no output while formatting! - 3 files have different output while reformatting twice! - 2 files have different output while reformatting twice but was expected! - 631 files have different output while reformatting twice but only by leading whitespaces! - 31 files have different output while reformatting twice but only by whitespaces! b) Galileo wksp - 3 files have no output while formatting! - 29 files have different output while reformatting twice! - 2119 files have different output while reformatting twice but only by leading whitespaces! - 197 files have different output while reformatting twice but only by white spaces! c) JDKs wksp - 4 files have unexpected failure while formatting! - 1 file has no output while formatting! - 121 files have different output while reformatting twice! - 917 files have different output while reformatting twice but only by leading white spaces! - 262 files have different output while reformatting twice but only by white spaces! I also ran the massive tests against 3.3.2: a) Eclipse 3.0 wksp - 1 file has no output while formatting! - 16 files have different output while reformatting twice but only by leading white spaces! - 1 file have different output while reformatting twice but only by white spaces! b) Galileo wksp - 3 files have no output while formatting! - 50 files have different output while reformatting twice but only by leading white spaces! - 3 files have different output while reformatting twice but only by white spaces! c) JDKs wksp - ? files have unexpected failure while formatting! - ? file has no output while formatting! - ? files have different output while reformatting twice! - ? files have different output while reformatting twice but only by leading white spaces! - ? files have different output while reformatting twice but only by white spaces! I didn't really matter about the different outputs when they were only due to white spaces because I thought that these were issues already existing in previous version before the comment formatter was rewritten in 3.4. It seems that I was wrong on that point! So, I set a high priority on this bug to have a chance to understand why these numbers are so high since 3.4 and try reduce them at the 3.3 level (or better) before 3.6 delivery and may be 3.5.2...
Ooops, I missed to refresh the numbers for 3.3.2 JDKs wksp: - 1 file has no output while formatting! - 143 files have different output while reformatting twice but only by leading white spaces!
Hmmm, my first analyse is that massive tests do not format the comments in 3.3.2 as 2 passes were needed before the comments formatter was rewritten in 3.4... Hence these numbers are not comparable and also hopefully explains why I didn't worry a lot about all these differences since 3.4 (I had frighten myself :-S). I'll dump comparable numbers soon...
Here are the numbers for 3.6 v_A16 without formatting comments: a) Eclipse 3.0 wksp - 1 file has no output while formatting! - 12 files have different output while reformatting twice but only by leading white spaces! - 1 file have different output while reformatting twice but only by white spaces! b) Galileo wksp - 3 files have no output while formatting! - 27 files have different output while reformatting twice but only by leading white spaces! - 3 files have different output while reformatting twice but only by white spaces! c) JDKs wksp - 1 files have no output while formatting! - 17 files have different output while reformatting twice but only by leading white spaces! Which are better than 3.3.2, hence there's no regression in the formatter. It's just a stability issue mainly due to comment formatting. I'll try to see if I can get numbers for 3.3.2 while formatting comments (which is a little bit more tricky as the second formatting pass that JDT/Text was performing in 3.3 version to format the entire compilation unit needs to be emulated...)
I got some issues to include the formatting of the comments using the 3.3.2 version while running the massive tests, but I finally succeeded to get the numbers: a) Eclipse 3.0 wksp - 1 file has no output while formatting! - 28 files have different output while reformatting twice! - 7 files have different output while reformatting twice but was expected! - 4501 files have different output while reformatting twice but only by leading white spaces! - 100 files have different output while reformatting twice but only by white spaces! b) Galileo wksp - 3 files have unexpected failure while formatting! - 3 files have no output while formatting! - 1 file has different output while comparing with previous version! - 193 files have different output while reformatting twice! - 3 files have different output while reformatting twice but was expected! - 20101 files have different output while reformatting twice but only by leading white spaces! - 216 files have different output while reformatting twice but only by white spaces! c) JDKs wksp - 2 files have unexpected failure while formatting! - 1 file has no output while formatting! - 329 files have different output while reformatting twice! - 13595 files have different output while reformatting twice but only by leading white spaces! - 24 files have different output while reformatting twice but only by white spaces! There are definitely worst, hence the formatter shows a real improvement in this area since 3.3... It just still has some instability I'll try to reduce in this version.
Would it be possible to get more details on what units provided no output on formatting ? I'd like to have a look at these units.
(In reply to comment #5) > Would it be possible to get more details on what units provided no output on > formatting ? > I'd like to have a look at these units. These are due to compilation errors which prevents the formatter to proceed normally. I verified that in the full source workspaces I use for the massive tests, the compilation syntax errors were justified, hence there's no real formatter issue with these invalid CU. I've changed the test suite to dump these specific errors...
> c) JDKs wksp > - 4 files have unexpected failure while formatting! > I've opened bug 294500 for this specific failure due to a MalformedTreeException
(In reply to comment #6) > These are due to compilation errors which prevents the formatter to proceed > normally. I verified that in the full source workspaces I use for the massive > tests, the compilation syntax errors were justified, hence there's no real > formatter issue with these invalid CU. I've changed the test suite to dump > these specific errors... If the syntax errors occurred inside a method body, they should not prevent the rest of the unit from being formatted. Could you please give me examples of syntax errors in this case ? Thanks.
(In reply to comment #8) > (In reply to comment #6) > > These are due to compilation errors which prevents the formatter to proceed > > normally. I verified that in the full source workspaces I use for the massive > > tests, the compilation syntax errors were justified, hence there's no real > > formatter issue with these invalid CU. I've changed the test suite to dump > > these specific errors... > If the syntax errors occurred inside a method body, they should not prevent the > rest of the unit from being formatted. > Could you please give me examples of syntax errors in this case ? > > Thanks. Sure, here they are: 1) Non Java code public class $perspectiveClassName$ implements IPerspectiveFactory { private IPageLayout factory; public $perspectiveClassName$() { super(); } public void createInitialLayout(IPageLayout factory) { this.factory = factory; addViews(); % if(actionSets) addActionSets(); % endif % if(newWizardShortcuts) addNewWizardShortcuts(); % endif % if(perspectiveShortcuts) addPerspectiveShortcuts(); % endif % if(showViewShortcuts) addViewShortcuts(); % endif } } 2) usage of enum package wksp1; public class X03 { void foo(int enum) {} } 3) usage of assert package wksp3; public class X01 { protected AWTEvent coalesceEvents(AWTEvent existingEvent, AWTEvent newEvent) { int id = existingEvent.getID(); if (assert) { // Enable assert to perform this extra sanity check, but it's too // expensive for normal operation. if (id != newEvent.getID() || !(existingEvent.getSource().equals(newEvent.getSource()))) { // Only coalesce events of the same type and source. return null; } } return null; } }
Created attachment 153921 [details] Proposed patch for M4 This patch passes all JDT/Core tests (of course) and imply one failure on JDT/UI tests (I'll post corresponding patch after)... I will shortly post all numbers on the full source workspaces to show the improvement...
Created attachment 153924 [details] Patch to fix failure in JDT/UI tests
Markus, make sure you synchronize with Frédéric to release the fix in JDT/UI tests.
Here the new numbers for the full source workspaces used for the formatter massive tests. Using the Eclipse built-in profile: a) Eclipse 3.0 wksp - 1 file has compilation errors which prevent the formatter to proceed - 7 files have different output while reformatting twice but was expected - 10 files have different output while reformatting twice but only by leading white spaces - 6 files have different output while reformatting twice but only by white spaces b) Galileo wksp - 3 files have compilation errors which prevent the formatter to proceed - 39 files have different output while reformatting twice - 1 file has different output while reformatting twice but was expected - 33 files have different output while reformatting twice but only by leading white spaces - 15 files have different output while reformatting twice but only by white spaces c) JDKs wksp - 1 file has compilation errors which prevent the formatter to proceed - 100 files have different output while reformatting twice - 131 files have different output while reformatting twice but only by leading white spaces - 50 files have different output while reformatting twice but only by white spaces Last numbers with v_A25 were: a) Eclipse 3.0 wksp - 1 file has compilation errors which prevent the formatter to proceed - 8 files have different output while reformatting twice but was expected - 711 files have different output while reformatting twice but only by leading white spaces - 7 files have different output while reformatting twice but only by white spaces b) Galileo wksp - 3 files have compilation errors which prevent the formatter to proceed - 43 files have different output while reformatting twice - 2 file has different output while reformatting twice but was expected - 2382 files have different output while reformatting twice but only by leading white spaces - 14 files have different output while reformatting twice but only by white spaces c) JDKs wksp - 1 file has compilation errors which prevent the formatter to proceed - 100 files have different output while reformatting twice - 1129 files have different output while reformatting twice but only by leading white spaces - 43 files have different output while reformatting twice but only by white spaces To summarize, this patch reduces the formatter instability: - 3.0 wksp: from 727 to 24 - Galileo wksp: from 2444 to 91 - JDKs wksp: from 1273 to 282
Created attachment 153944 [details] New proposed patch for M4 This new patch fixes an additional issue with comments on the first line of array initializer when the 'Brace Next Line' option is set...
Released for 3.6M4 in HEAD stream.
Most of the instabilities have been fixed and there are very few left for which I will open separate bugs.
Verified for 3.6M4 using Build id: I20091207-1800
*** Bug 188119 has been marked as a duplicate of this bug. ***
