Summary: | [compiler] suboptimal line number attributes for cascading field accesses | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Olivier Thomann <Olivier_Thomann> |
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | maxime_daniel, philippe_mulet |
Version: | 3.3 | ||
Target Milestone: | 3.3 M6 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Olivier Thomann
2007-02-11 15:48:54 EST
Now I fail on line 12, not 11 though. The field on line 11 is null, but the access is failing only in line 12 when the field is accessed. Does this look better? The cascading field reference case is also wrong. public class X { X x; X next; X (X next) { this.next = next; } public static void main(String args[]) { X x = new X(new X(new X(null))); x.x = x; x.foo(); } public void foo() { this. x. next. next. next. next. next. toString(); } } Since the field references are sharing the source start, we must use the source end position. Fix under testing. (In reply to comment #1) > Now I fail on line 12, not 11 though. > The field on line 11 is null, but the access is failing only in line 12 when > the field is accessed. > Does this look better? > Ideally, the line reported should be the one of 'the dot that fails'. But IMHO, the line of the first selector that follows it is OK as well, or the line of the selector that yields the null value (better?), provided that we are consistent and the user can rely on us to be consistent (then a test on a simple case will give her a clue of what to expect). (In reply to comment #3) > Ideally, the line reported should be the one of 'the dot that fails'. But IMHO, I disagree. The dot itself means nothing. It is the subsequent field access that will fail. If you write your test case: x .next .next .... I would expect the same line to be returned. I have one last issue to solve before I can release the fix. Released for 3.3M6. (In reply to comment #4) > (In reply to comment #3) > > Ideally, the line reported should be the one of 'the dot that fails'. But IMHO, > I disagree. The dot itself means nothing. It is the subsequent field access > that will fail. The dot is the common part of the syntax for dereference, for multiple uses (field access and method call). This may not be the best candidate, but it means at least that. Verified for 3.3 M6 using build I20070320-0010 |