Community
Participate
Working Groups
3.1M7 public class Foo //implements List { private Object x; void set(T1 x){ this.x= x; } } quick fix the compile error by selecting "add type parameter" you get: public class Foo //implements List<T1> { private Object x; void set(T1 x){ this.x= x; } } (fyi: quick fixing again adds another <T1> :) )
btw this only happens in this one comment+line break constellation, as far as I can tell
has to wait for 3.2, too risky to turn screws in the ast rewriter now
*** Bug 103340 has been marked as a duplicate of this bug. ***
API requested in bug 113108 would give me the possibility to find out that the last comment is a line comment. So I could decide either to not map the comment to the name, or go to the next line when inserting.
*** Bug 114418 has been marked as a duplicate of this bug. ***
Martin, Before adding AST API, I'd like to understand a bit more about why the quick fix is making this mistake. The source range of an end-of-line comment includes the line end delimiter. Presumably, the comment in the example is either considered a trailing comment of the "Foo" SimpleName node (comment included in extended source range of SimpleName node), or an interior comment of the class declaration (comment not included in extended source range of SimpleName node). In the first case, the type parameter node should end up being inserted after the extended source range of the name, which would place it on the following line: public class Foo //implements List <T1>{ In the second case, the type parameter node should end up being inserted after the extended source range of the name, which would place it before the comment: public class Foo<T1> //implements List { How do you explain the observed behavior, which is neither of the above?
The new line delimiter is currently not contained in single line comments. That's a long discussed issue, which I didn't dare to challange (again).
*** Bug 128818 has been marked as a duplicate of this bug. ***
*** Bug 134439 has been marked as a duplicate of this bug. ***
*** Bug 137873 has been marked as a duplicate of this bug. ***
*** Bug 128422 has been marked as a duplicate of this bug. ***
Created attachment 39676 [details] proposed fix for RC2 Fixes the problem by detecting insertions after line comments and inserting a new line delimiter. Does not care about formatting: Result is mostly strangly formatted, but code isn't corrupted anymore. Doesn't yes fix insertion after copied nodes with new line comments (bug 128422). But all other duplicates are fixed and covered in the tests. David, can you review?
This patch looks good and work as described in comment 12.
+1 for 3.2RC2
Fixed and released in HEAD.
Verified with I20060427-1600 for RC2.