Community
Participate
Working Groups
Variable hover displays the value of the this member when hovering over the same member in a different object of the same type. For example: public class Foo { private int id; public boolean equals(Object other) { Foo that = (Foo)other; return this.id == that.id; } } Setting a breakpoint at the return statement and hovering over the id in "that.id" displays the value of "this.id".
Currently, the debug hover is only resolving the identifier under the cursor (in this case 'id'). If finds a field and resolves it in the context of "this", rather than checking for a qualifier.
Marking as assigned for future consideration. Not planned for 3.3.
*** Bug 199223 has been marked as a duplicate of this bug. ***
*** Bug 246142 has been marked as a duplicate of this bug. ***
This blooper cost me quite some time. I was really perplexed until I found out that it's not me who doesn't understand what's going on, but the Variable Value hover. JavaDebugHover#resolveLocalVariable(IJavaStackFrame, ITextViewer, IRegion) should at least scan backwards a bit and return null if the tokens in front of the given region are "<identifier><whitespace>?'.'<whitespace>?" where <identifier> is not "this". Even better would be to use an AST (from SharedASTProvider) and walk up the tree to make sure the variable is really from the current context. Or even resolve the parents as well, such that the hover can show the right value for simple chains such as "that.id".
*** Bug 308514 has been marked as a duplicate of this bug. ***
Created attachment 164263 [details] Fix Here's a straightforward fix that creates its own minimal AST and ensures that the variable hover is only shown for field accesses on 'this'. In the example from comment 0, the wrong variable hover just doesn't show up any more for "id" in "that.id" (but the user can still hover over "that" to the see "id" as a child in the hover).
Applied. Fixed. Thanks, Markus.
Verified.
Created attachment 164578 [details] Fix 2 (use SharedASTProvider) If the SharedASTProvider already has an AST for the type root, we could save some work. The patch does that, but still creates its own minimal AST in other cases (since that's still faster than waiting for the full AST).
re-open for improvement.
Applied.
Sorry, I messed up. The check is far too restrictive, since it prevents the hover in all cases where the field is accessed without qualifier. Here's a test case: package xy; public class Foo { protected int id; public static void main(String[] args) { final Foo a = new Foo(); a.id = 42; final Sub b = new Sub(); b.id = 0; System.out.println(a.equals(b)); System.out.println(a.id); System.out.println(new Foo().id); } public Foo() { id= 17; System.out.println(id); } public boolean equals(Object other) { final Foo that = (Foo) other; return this.id == that.id; } } class Sub extends Foo { public Sub() { System.out.println(super.id); } }
Created attachment 164865 [details] Fix 3 (corrects condition) Luckily, there are only two constructs in the AST where a field name can refer to a field in another instance: FieldAccess and QualifiedName. This patch only prevents the "remote field access" cases but allows all the others.
Good catch. Applied.
