Bugzilla – Full Text Bug Listing
| Summary: | Binding recovery fails for the other occurrences of a unresolvable binding (making createASTs order dependent) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Davy Landman <davy.landman> | ||||||||
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||||
| Severity: | minor | ||||||||||
| Priority: | P3 | ||||||||||
| Version: | 4.5.2 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Mac OS X | ||||||||||
| Whiteboard: | stalebug | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 260047 [details]
NestedClass1.java
Created attachment 260048 [details]
test files used in the Examples.
My bad, forgot every attachment send new emails, here are all the files attached.
Since they are quite short, here are the contents:
class NestedClass1 {
public Foo.Bar method1() { return null; }
}
class NestedClass2 {
public Foo.Bar method2() { return null; }
}
class QualifiedName1 {
public org.google.Test method1() { return null; }
}
class QualifiedName2 {
public org.google.Test method2() { return null; }
}
class QualifiedNameGeneric {
public org.google.Test<A> method() { return null; }
}
(In reply to Davy Landman from comment #0) forgot to paste the output of the code: Binding recovery single file: Single class (nested) => Success Single class (qualified) => Success Single class (qualified-generic) => Failed Binding recovery multiple file: Target 1st (nested) => Success Target 2nd (nested) => Failed Target 1st (qualified) => Success Target 2nd (qualified) => Success 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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. |
Created attachment 260046 [details] Runner file We've been using JDT for quite a while now to extract bindings from java code. Thanks for the work! Recently we observed that sometimes MethodDeclaration bindings were missing. After quite some debugging we found that for certain Types that can't be solved (incomplete class path) and that they only get solved the first time. The second time JDT sees the same Type, it will put a null there, and this cascades through. The examples I've made are for return types, but the same problem occurs with them as argument of the method. In the attachment there is the code I've used to reproduce this bug. The strange thing is, given two files with the same unsolvable type in them, the first file in the array of ASTParser.createASTs get's a type binding, while the rest will get a null type binding. This contradicts the documentation of ASTParser: "The compilation units are processed one at a time in no specified order.". I've tried debugging, and it seems in case of a unsolvable type, it guesses a rough type, and put's it into the typeOrPackageCache cache of the CompilationUnitScope, but there is a difference between the first time it puts it in there, and subsequent retrieval from the cache. I think it is related, so I didn't make a separate issue for it. But in case of a qualifiedName with a generic argument, it always fails, no order dependence.