Bug 24449 - AST: Resolve on field access
Summary: AST: Resolve on field access
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 2.1 M2   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-10-07 09:36 EDT by Martin Aeschlimann CLA
Modified: 2002-11-25 09:06 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Aeschlimann CLA 2002-10-07 09:36:56 EDT
20021001
Similar as bug 24406, again for quick fix:
Would it be possible to get the FieldAccess bindings to non-visible / non 
static fields?

public class C {
  private int fCoo;
}

public class D {
  public static void goo(C c) {
    fCoo= 1;
    super.fCoo= 1;
    C.fCoo= 1;
    c.fCoo= 1;
  }
}
Comment 1 Martin Aeschlimann CLA 2002-10-07 09:43:38 EDT
Same for types:

public class C {
  private class CInner {
  }
}

public class D {
  public static void goo() {
    CInner c;
  }
}
Comment 2 Olivier Thomann CLA 2002-10-07 12:01:09 EDT
In this case, I cannot do anything. The binding of the SingleNameReference is
null and because of the static context I cannot retrieve a scope to do the
resolution. So no hope in this case.
Ok to close as WONTFIX?
Comment 3 Martin Aeschlimann CLA 2002-10-07 12:45:43 EDT
I got it working by rudely (and naivly) removing binding.isValidBinding() in
DefaultBindingResolver.resolveName, line 218

 // this is a variable or a field
 Binding binding = singleNameReference.binding;
 if (binding != null) {  << removed here

and getVariableBinding, line 686
  if (variableBinding == null) { << removed here
    return null;
  }

What do you think? 
Comment 4 Martin Aeschlimann CLA 2002-10-07 12:50:28 EDT
Sorry forgot another one at line 123.

Comment 5 Olivier Thomann CLA 2002-10-07 13:03:10 EDT
I will investigate, but I don't want to hack the code in order to have one or 
two quickfixes ok. We have to be able to explain why something is not 
resolvable.
Bug 24453 is a priority. I will have a look again at this one, but I don't see 
how removing null checks can improve something. In your first test case, the 
binding of the single name reference is null. So I think it is safe to return 
null at this point, isn't it?
Comment 6 Martin Aeschlimann CLA 2002-10-07 13:19:19 EDT
Oops, bug in my code example:
public class D extends C {

Otherwise it can only be null, of course, as you say.
If the 'extends' is there, the DefaultBindingResolver has bindings but returns 
null as the binding.isValidBinding returns false: The binding has error code
ProblemReasons.NotVisible or ProblemReasons.NonStaticReferenceInStaticContext.


Comment 7 Olivier Thomann CLA 2002-10-07 13:35:29 EDT
I was talking about this example:
public class C {
  private int fCoo;
}

public class D {
  public static void goo(C c) {
    fCoo= 1;
    super.fCoo= 1;
    C.fCoo= 1;
    c.fCoo= 1;
  }
}

In this case there is nothing I can do. I simply don't have a binding. I will 
investigate the second example.
Comment 8 Olivier Thomann CLA 2002-10-07 14:35:17 EDT
In this case,
public class C {
  private int fCoo;
}

public class D {
  public static void goo(C c) {
    fCoo= 1;
  }
}

There is nothing I can do.

This case is fixed:
public class C {
  private class CInner {
  }
}

public class D {
  public static void goo() {
    CInner c;
  }
}

And will try the different other cases for:
    super.fCoo= 1;
    C.fCoo= 1;
    c.fCoo= 1;
Comment 9 Olivier Thomann CLA 2002-10-07 15:25:04 EDT
super.fCoo= 1;  FAIL
C.fCoo= 1;      OK
c.fCoo= 1;      OK

Closed as FIXED.
The two corner cases:
    fCoo= 1;
    super.fCoo= 1;
won't be fixed.
Fixed and released in HEAD. Regression tests added.
Comment 10 Martin Aeschlimann CLA 2002-10-08 04:28:42 EDT
Thanks a lot!
My code missed the 'extends C' statement. Can you try this?

public class C {
  private int fCoo;

  private class CInner {
  }
}

public class D extends C {
  public void goo(C c) {
    fCoo= 1;
    super.fCoo= 1;
    C.fCoo= 1;
    c.fCoo= 1;
    
    
    C.CInner a;
    CInner b;
  }
}

I took the latest code from HEAD. fCoo= 1; fails and C.CInner a; CInner b; fail 
as well.

Sorry for the trouble. But the more bindings we get, the more we can offer when 
working on almost correct code. So this thing is really helpful.
Comment 11 Martin Aeschlimann CLA 2002-10-08 05:25:27 EDT
Another case: Can't resolve coo2() in the constructor C()

public class C {
	private C() {
		this(coo2());
	}
	
	private C(int i) {
	}

	private int coo2() {
		return 7;
	}
}
Comment 12 Olivier Thomann CLA 2002-10-08 09:06:38 EDT
Please open different PRs for such problems. It is not trivial to cover all 
test cases added in a single PR.
I close this one and please open a new one for the member visibility and for 
the method invocation in the constructor invocation.
As I said before, fCoo= 1; won't be fixed. In this case I don't have any 
binding on which I can do some lookup.