Community
Participate
Working Groups
This relates to an issue I have found while trying to implement a quick fix for a missing type: https://github.com/bndtools/bnd/blob/e6cd6fd0b6ef484035dea0ab9f71f3cf1d1e199d/bndtools.core.test/src/bndtools/core/test/editors/quickfix/BuildpathQuickFixProcessorTest.java#L856-L878 The test case (which runs against Eclipse 2018-12): I have a compiled class "ClassWithInterfaceExtendingMyInterface" that implements an interface "InterfaceExtendingMyInterface". The class is on the classpath while the interface is not. The source contains a TypeLiteral construct (which references "ClassWithInterfaceExtendingMyInterface") as a parameter to an annotation. I walk the AST hierarchy until I find the Type node for the TypeLiteral. Calling resolveBinding() on this Type node successfully gives me binding information for "ClassWithInterfaceExtendingMyInterface". When I call toString() and get a dump of this binding, the text output indicates that the type implements "InterfaceExtendingMyInterface" and that the binding for "InterfaceExtendingMyInterface" is not resolved. Further, if I inspect the fields of the binding for "ClassWithInterfaceExtendingMyInterface" in the debugger, I can see that that there is an "unresolved binding" object in there corresponding to the "InterfaceExtendingMyInterface". Everything up until now is as expected. The surprising thing, however, is that when I call getInterfaces() on the type binding object for "ClassWithInterfaceExtendingMyInterface", it comes back with an empty array. I expect it to return an array containing the single element containing the unresolved binding information for "InterfaceExtendingMyInterface". I apologise if this is user error - I did try extensively before filing the bug. I also searched for a pre-existing issue and didn't find one, so again I apologise if there is one.
Just a note that this bug is still present in Eclipse 2020-06.
Another note: this bug does not only affect type literals. Consider this case: Suppose that ClassWithIntermediateInterface implements IntermediateInterface, and IntermediateInterface extends Serializable. Suppose that IntermediateInterface is not on the classpath. List<Serializable> l = new ArrayList<ClassWithIntermediateInterface>(); This will cause a TypeMismatch. However, although bindings recovery is on, when I call getInterfaces() on the type binding for ClassWithIntermediateInterface, it returns an empty array. I expect it to return the incomplete (recovered) binding for IntermediateInterface. If you call toString() on the type binding for ClassWithIntermediateInterface, it lists the interface as "unresolved", so the binding "knows" about its interfaces enough to print it in the toString() but for some reason doesn't return them when you try and fetch them directly.
Another example of this bug: A class in my current project (say "my.pkg.MyClass") instantiates a particular type "some.pkg.A". This type has a constructor with type "some.otherpkg.B" as a parameter. "A" is on the classpath but "B" is not. This doesn't compile ("IProblem.MissingTypeInConstructor"), which is expected. However, when I look at the AST for "my.pkg.MyClass" and the ClassInstanceCreation node where the error is occuring, even though bindings recovery is on, some of the important binding information is missing. Specifically, the recovered binding for "B" is missing the package portion of the binding. This is in spite of the fact that this information should be available to the bindings resolver (the package name should be stored in the class definition for "A", which is on the classpath). Consequently, the ITypeBinding for "B" resolves relative to the package for "MyClass" rather than in its own package (ie "my.pkg.B" rather than "some.otherpkg.B"). Because the correct FQN of the class is unavailable it makes it harder to do a accurate class lookup.
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.
