Bugzilla – Full Text Bug Listing
| Summary: | Problem marker with inconsistent data | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Thirumala Reddy Mutchukota <thirumala> | ||||
| Component: | Core | Assignee: | ANIRBAN CHAKRABORTY <anchakrk> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | anchakrk, jarthana, srikanth_sankaran, tparker | ||||
| Version: | 4.3.1 | ||||||
| Target Milestone: | 4.4 M4 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
When I looked more closely, I found that the lineEnds contain only the line breaks in the file and doesn't contains the end position of the last line. Due to that when the offset is outside the last lineEnd, it's not appropriate to put the marker on the line 1 because, the last line might have some code and the error is actually corresponds to that. I tried to set the problemStart and problemEnd positions to 0 when the line number is the last line, but that too didn't work. The same worked fine when line number is last but one line. I am not sure what's going on here. I would try to look at it again when I get little free from my other high priority tasks and meanwhile it would be great if some one who has more knowledge in this part of code base would look at it. The steps to reproduce this problem is available in https://bugs.eclipse.org/bugs/show_bug.cgi?id=420032. Anirban, please take a look at this for M4. I can help with any reviews. TIA. Hello, my findings are the following: The Util.getLineNumber(int position, int[] lineEnds, int g, int d) calculates the line number at the 'position' based on the information present in the 'lineEnds' array (in a binary search procedure, logarithmically decreasing the search space). 'g' and 'd' are line-number-bounds provided between which the line number should lie. But in the situation you mentioned, the error location is into the last line, and hence outside the bound that is provided by g to d. In such a scenario the behavior is undefined. One might argue this function is called in an unintended way. Let Srikanth comment whether to increase the scope of the function to handle one line ahead [ for eg by adding an instruction like : if (position > lineEnds[d]) return d+2; ]; or whether to ask to caller to adhere to the discipline. Thanks Anirban (In reply to ANIRBAN CHAKRABORTY from comment #3) > Let Srikanth comment whether to increase the scope of the function to handle > one line ahead [ for eg by adding an instruction like : if (position > > lineEnds[d]) return d+2; ]; or whether to ask to caller to adhere to the > discipline. If it is returning an incorrect line number, it needs to be fixed. (In reply to Srikanth Sankaran from comment #4) > (In reply to ANIRBAN CHAKRABORTY from comment #3) > > > Let Srikanth comment whether to increase the scope of the function to handle > > one line ahead [ for eg by adding an instruction like : if (position > > > lineEnds[d]) return d+2; ]; or whether to ask to caller to adhere to the > > discipline. > > If it is returning an incorrect line number, it needs to be fixed. I think here the problem is not with the Util.getLineNumber method. It's trying to calculate the line number based on the information provided to it and when it's not able to find it, returning the best approximated line number. It seems it's already returning the d+2 when the position is greater than lineEnds[d]. And I believe the actual problem is with org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(int, String[], int, String[], int, int, int, ReferenceContext, CompilationResult) method. It is creating the problem marker with original offsets (problemStartPosition, problemEndPosition) and the approximated line number returned by Util.getLineNumber. Due to that, the mentioned problemStartPosition may not belong to the liner number mentioned in the problem and due to that editor is not showing the error marker. I think this method should take that (the Util.getLineNumber may return approximated line number) into consideration and take the required remedies to create problem with valid data so that editor will show it to the user. in org.eclipse.jdt.internal.compiler.parser.Scanner.getLineEnds(), what it would mean to create an extra trailing entry that is set to the last EOF offset ? Let us see we have seen 5 lines so far 1 76 2 96 3 98 4 112 5 167 getLineEnds() would have the rest of the world believe that the line ends are actually 1 76 2 96 3 98 4 112 5 167 6 123456 // file has 123456 characters. Hello, The problem is occurring due to, the line number it is getting is not about that same file. While it is trying to get the line number in the file B.java (with the help of lineEnds array), because that is the compilation unit, the real position being send is about the field declaration, which is in A.java. That's why the line number calculation is wrong, and hence nothing is getting printed. Planning to send the location of reference, for the calculation of the line number, so that the error shows up in the adjacent. Thanks Anirban Created attachment 237670 [details]
Uploading the code patch.
Uploading the code patch. This will show the error marker adjacent to the field reference.
Will upload testcase soon.
Hi Anirban, Thanks for the patch and looking into this issue. I reported the same issue under the compiler (https://bugs.eclipse.org/bugs/show_bug.cgi?id=420032) to report the error properly and I think your patch is the right candidate for that issue. I feel it's great to fix the reporting issue but still thinks it's good to fix the issue in problem marker creation too (this issue), so that when compiler reports some wrong information the user can see the problem in the editor some where and can access the quick fixes. Thanks, Thirumal. (In reply to ANIRBAN CHAKRABORTY from comment #8) > Created attachment 237670 [details] > Uploading the code patch. > > Uploading the code patch. This will show the error marker adjacent to the > field reference. > Will upload testcase soon. > I feel it's great to fix the reporting issue but still thinks it's good to
> fix the issue in problem marker creation too (this issue), so that when
> compiler reports some wrong information the user can see the problem in the
> editor some where and can access the quick fixes.
>
Hello Thirumala,
Thanks for your comments. But the patch does that, i.e, put the error marker against the 'bad' line in the current file in the editor. The user can go to the line and make appropriate change. If the change has to done somewhere else, the user has to fix there. Please note, all errors do not have a quick fix, because that might not be correctable within the setup. Pointing the error and correct location is the primary aim. Quick fix might be there, if possible.
Thanks
Anirban
Hello, I also see, if I click on the error marker (shown adjacent to the file reference), Quick Fix comes up suggesting "Configure Build paths". Is there anything more to be done on this? Thanks Anirban
> I also see, if I click on the error marker (shown adjacent to the file
Typo: please read as "shown adjacent to the field reference"
*** This bug has been marked as a duplicate of bug 420032 *** |
Sometimes the compiler is reporting the problem start and end offsets outside the source file (I am trying to create simple reproducible case for that and will report that in a different bug). When it happens the problem marker is getting created at the last line of the file (because the problem offset is beyond the last line offset). But in the problem marker, that charStart and charEnd offsets are set to the values reported by compiler, which are not belonging to the last line of the file. Due to that the problem marker is shown only the Problems View and not shown in the editor and user doesn't have access to the quick fixes. Here is snippet of the code which is computing the line number. from org.eclipse.jdt.internal.compiler.util.Util.getLineNumber(int, int[], int, int) int[] lineEnds; int lineNumber = problemStartPosition >= 0 ? Util.getLineNumber(problemStartPosition, lineEnds = unitResult.getLineSeparatorPositions(), 0, lineEnds.length-1) : 0; int columnNumber = problemStartPosition >= 0 ? Util.searchColumnNumber(unitResult.getLineSeparatorPositions(), lineNumber, problemStartPosition) : 0; CategorizedProblem problem = this.createProblem( unitResult.getFileName(), problemId, problemArguments, elaborationId, messageArguments, severity, problemStartPosition, problemEndPosition, lineNumber, columnNumber); from org.eclipse.jdt.internal.compiler.util.Util.getLineNumber(int position, int[] lineEnds, int g, int d) { if (lineEnds == null) return 1; if (d == -1) return 1; int m = g, start; while (g <= d) { m = g + (d - g) /2; if (position < (start = lineEnds[m])) { d = m-1; } else if (position > start) { g = m+1; } else { return m + 1; } } if (position < lineEnds[m]) { return m+1; } return m+2; } When the position > lineEnds[d], the marker is getting created on the last line of the file with the original start and end offsets. I think a better solution here would be that, when the position > lineEnds[d], return 1 as the line number and when start and end offsets are outside the line offsets, set them to beginning of the line, so that the error marker is shown to the user in the editor and he/she have access to the quick fixes. I am working on the fix and send it across soon. Meanwhile please let me know if there are any objection with my proposal.