Community
Participate
Working Groups
Created attachment 281978 [details] Reproducer See attached reproducer - it fails with org.eclipse.jdt.core version 3.20.0 from maven central as well as with 3.21.0-SNAPSHOT, built locally, from BETA_JAVA14 branch (https://github.com/eclipse/eclipse.jdt.core/commit/964325af9709ba62fa989bec14800789b319273e). The first character of the comment (index 55) is expected to be on line 4, got line 3.
@Michael, Comments are not shown in AST view. It is not shown after normal String or any variable declaration also by design. Has something stopped working for you?
@Sarika Comments are indeed not part of the AST view. However, do you still expect then to have differences in terms of character positions (lines) between AST and original sources? That's not what I understand from the javadoc of CompilationUnit.getLineNumber(int). "Returns the line number corresponding to the given source character position in the original source string." On our side (SonarQube) we are highlighting tokens differently depending of their type. With Textblocks, we experienced misalignment of tokens according to the AST, hence is the minimal reproducer. If you take character 66 ('}'), not part of comment, from the same reproducer, I still expect to get line 5, while I currently get line 4.
Will look at the feasibility of providing this after Java 14 release.
Moving to M3.
Created attachment 283849 [details] Similar example reproducing the issue
We have a similar issue (SourceLines.java file) related to line numbers and comments. In this example, getLineNumber() for simple name SourceLines returns 6 instead of 9. For most of other nodes wrong line number is returned also. Should I file a different bug or this is the same issue?
P.S. We are using org.eclipse.jdt.core version 3.22.0.
I tried running against a 4.16 Eclipse (jdt.core 3.22.0) target platform and it does fail. However, it passes against 4.17 I-build (jdt.core 3.23.0). I managed to find Bug 565639, and if I revert just that commit, I can fail it on 4.17 I-build so maybe that was what fixed things. If I take the Reproducer test and adjust it for the 'SourceLines' snippet, it always seems to pass for me.
(In reply to Roland Grunberg from comment #8) > I tried running against a 4.16 Eclipse (jdt.core 3.22.0) target platform and > it does fail. However, it passes against 4.17 I-build (jdt.core 3.23.0). I > managed to find Bug 565639, and if I revert just that commit, I can fail it > on 4.17 I-build so maybe that was what fixed things. > > If I take the Reproducer test and adjust it for the 'SourceLines' snippet, > it always seems to pass for me. Ok, Looks like this change has fixed it. if ((this.currentCharacter == '\r') || (this.currentCharacter == '\n')) { if (this.recordLineSeparator) { pushLineSeparator(); } } @Jay, any comments?
(In reply to Sarika Sinha from comment #9) > @Jay, any comments? If we are talking about text block (or even otherwise) and anything related to line number not being correct, yes, bug 565639 must be the one.
Apparently this is the same as bug 565639 - confirmed with original reporter that upgrade to org.eclipse.jdt.core 3.23.0 solves the issue, so closing as duplicate.
*** This bug has been marked as a duplicate of bug 565639 ***
