Community
Participate
Working Groups
As of 4.5.1 using any of the built-in formatter profiles, the formatter is capable of joining two lines even if the first line ends in a single-line comment. Example Before auto-formatting public class AutoFormatTest { public AutoFormatTest subtest = new AutoFormatTest("Test1", // comment "Test2"){ }; public AutoFormatTest(String foo, String bar) { } } After auto-formatting public class AutoFormatTest { public class AutoFormatTest { public AutoFormatTest subtest = new AutoFormatTest("Test1", // comment"Test2") { }; public AutoFormatTest(String foo, String bar) { } } This only seems to occur when the second line contains the opening brace to an anonymous class.
This is because the formatter doesn't get information about the comment from the parser. I can see in the ASTView that the comments list is empty with given code. Another example I bumped into: public enum Enum impelements //comment Runnable { } The //comment doesn't show up in ASTView and the formatter joins this line. I see this problem in 4.4 too, although it doesn't affect the formatter there.
New Gerrit change created: https://git.eclipse.org/r/59447
Gerrit change https://git.eclipse.org/r/59447 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=64a9849f02ddb4edcc4fd1f600d032fb0cfb2765
(In reply to Eclipse Genie from comment #3) > Gerrit change https://git.eclipse.org/r/59447 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=64a9849f02ddb4edcc4fd1f600d032fb0cfb2765 Thanks Mateusz. Please backport this to 4.5.2 as well
Backported with http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=R4_5_maintenance&id=2ddacf3219eaa00c42644eeb41a9c8d3b06184e6
Somehow patch 3 in https://git.eclipse.org/r/#/c/59447 which got merged to master does not contain the copyright notice year update, even though it was there in patch 2. The backport commit was a cherrypick of that, so it also doesn't update the year. Manoj, did you do it intentionally? If not, is it important enough to fix it with subsequent commits?
(In reply to Mateusz Matela from comment #6) > Manoj, did you do it intentionally? If not, is it important enough to fix it > with subsequent commits? I think its an oversight or an error arose out of merge conflicts. During the later milestones, we look for missing ones and update the copyrights that should include candidates like this.
Verified for 4.5.2 with build M20160113-1000. and Verified for 4.6 M5 with build I20160112-1800.