Bugzilla – Full Text Bug Listing
| Summary: | Expression#resolveTypeBinding returns wrong type for SimpleName inside QualifiedName | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Andreas Thies <andreas.thies> | ||||||
| Component: | Core | Assignee: | Jesper Moller <jesper> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | manoj.palat, srikanth_sankaran, stephan.herrmann | ||||||
| Version: | 4.2 | Flags: | jesper:
documentation-
stephan.herrmann: review- |
||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | stalebug | ||||||||
| Attachments: |
|
||||||||
Jesper, please take a look, TIA. How about an explanation such as this: Note that 'resolveTypeBinding' returns a binding based on how the construct is is resolved, in context. For instance, if the expression 'obj.field' is a field reference to 'field' inside the class A, the type binding returned for 'obj' would return a binding for 'A', even if the declared type of obj was a subclass of A. In this case, fieldAccess.getExpression().resolveTypeBinding() == fieldAccess.resolveFieldBinding().getDeclaringClass(). Created attachment 228391 [details]
Patch for JavaDoc
Explanation about how the of binding context influences type binding results.
Stephan, can you look over the changes ? TIA. I have two comments:
(1) "even if <code>obj</code> was declared as a subclass of <code>A</code>."
obj cannot *be* (declared as) a subclass of A.
The original proposal was more accurate:
"even if the declared type of obj was a subclass of A"
Alternatively we could say "obj resolves to a variable/value(?) of a type B,
where B is a subclass of A".
(2) " ... is resolved based on the context .... For example "
This leaves me puzzling what other examples exist where context is relevant.
From the text I'd guess that all "receiver expressions", left of the dot
in a field access or method invocation are affected, and that the effect
is always to use the declaringClass of the feature right of the dot.
Is this guess correct? The javadoc should leave no doubt about this.
What kind of expressions 'obj' are affected? Only names or arbitrary
expressions?
ping :) ping' :) Created attachment 236601 [details]
New patch suggestion
Wow, those ping show horrible lagging...
This wording is closer to the original comment, is it better that way?
Talk about lagging, OMG! Yes, the proposed javadoc looks good per se. I'm only surprised about the facts, which we are documenting here: What you write seems to apply to field access only, replace b.i with b.getI() (with the obvious decl. of getI() in A), and b will have type B. Is this inconsistency intended? Manoj, have you seen such behavior? This seems to be implemented in DefaultBindingResolver:1081 ff, see: // in this case we want to get the next field declaring's class A little down that code we do use ((FieldBinding) qualifiedNameReference.binding).type which assumably would let us answer B instead of A, but this is done under the premise "no capture needed for array type". Maybe we should just use the qnr.binding.type and perform capture manually? (This region has not been touched since 2005). I don't know if clients might by now rely on the current semantics, or if we should consider this as a bug and fix the behavior, not the javadoc? Closing review as -1 based on comment 9. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Steps to reproduce: 1) Generate AST (with bindings) for package a; public class A { int i; B b = new B(); int x = b.i; } class B extends A { public int x; } 2) Find the SimpleName 'b' inside the QualifiedName 'b.i' 3) Call simpleName.resolveTypeBinding() on the SimpleName 'b' 4) This returns the type Binding 'public class a.A ...' Since b is declared with type B, I would expect the type Binding for the SimpleName 'b' to be 'class B ...'. For the case that this behavior is intended (e.g., because the type A would be sufficient as a receiver for the reference to i in b.i), the JavaDoc of Expression#resolveTypeBinding should clarify this.