Community
Participate
Working Groups
If you have a // comment inside an if statement and do a Source/Clean up... and select Always for "Use parentheses around conditions" you will get a slight code corruption: See example Before: ------------ if (a == 1 // || b == 2) { System.out.println("Hello World!"); } ------------ After: ------------ if ((a == 1 //) || (b == 2)) { System.out.println("Hello World!"); } ------------ As you can see the parenthesis is located to the right of the comment mark instead of to the left of the comment mark. An annoying bug, but not very bad.
Move to JDT/UI
what build are you using? This should be fixed
Sorry, just reproduced in RC4.
(In reply to comment #3) > Sorry, just reproduced in RC4. > And I'm using RC5 for the moment.
*** Bug 161862 has been marked as a duplicate of this bug. ***
*** Bug 184703 has been marked as a duplicate of this bug. ***
Martin, if you want me to fix this I'll do it, but I would need some help from you where to start...
Is there something I can do to help? I haven't yet tried to do anything with Eclipse sources, so I'm not sure. Just out of curiosity, why is this not considered major or critical? It breaks code, something a code formatter or cleaner IMO should never do. It's a rare occurrence, but I was more than just a bit surprised when my code suddenly turned red. Again, if there's something I can do to help, please let me know.
I'll have a look at it
*** Bug 128422 has been marked as a duplicate of this bug. ***
Created attachment 66862 [details] patch
Jerome and David, do you approve?
The fix avoids the compilation error by adding an line delimiter after the line comment. That means for the given example, the closing parenthesis is added on the new line. This is not elegant, but if we want to change that, we would have to tune the comment mapping heuristic, which is too sensitive at this time. Currently the comment is mapped to the preceding symbol ('1') what needs to be respected by the copy, remove or insert operations.
(In reply to comment #13) > The fix avoids the compilation error by adding an line delimiter after the line > comment. That means for the given example, the closing parenthesis is added on > the new line. This is not elegant Maybe. But line comments inside binary expression are ugly anyway. As long as the code compiles, any fix is fine for me. The cleanup should be to remove these comments :-).
Created attachment 66877 [details] additional test additional test that shows why b= offset < formatted.length() && !IndentManipulation.isLineDelimiterChar(formatted.charAt(offset)) is necessary
The patch do exactly what described in comment 13. The patch is good for me.
patch released > 20070514
Verified for 3.3 RC1 using I20070515-0010