Community
Participate
Working Groups
Build 206 + latest JDTCORE from HEAD (V_206_02). In a self-hosting workspace, I cannot obtain references to the constructor of Parser (in jdtcore). An AbortCompilation error is thrown when initializing the match locator(SuperTypeNamesCollector#collect()). It seems that some of the candidate declarations are being resolved in the wrong context. In this case, a candidate match is a Parser of xerces, which is being resolved in the context of org.eclipse.jdt.core.tests. Since xerces is in binary form, and the jdtcore tests do not prereq it on their classpath, an AbortCompilation is thrown (inconsistent binaries) from the type resolver. I made a hack to work around this defect (catch AbortCompilation in the #collect() method); but all matches should not be attempted to be resolved for initializing the polymorphic search (only those in the classpath). A simpler test case would likely be: P1 +- p1.jar +- p1 +- X.java X() +- Z.java reference to P1/p1.X() P2 prereqs P1 on its classpath +- p1 +- X.java X() P3 prereqs P2 on its classpath +- Y.java reference to P2/p2.X() When searching references to P2/p1.X(), it should fail in a similar fashion.
There were 2 problems: - the AbortCompilation exception was due to the fact that we were trying to cache an inner binary type in the lookup environment before its enclosing type. - the xerces.jar is not visible to org.eclipse.jdt.core.tests as Philippe stated. Fixed 1st problem by forcing the caching of the enclosing types before a binary type is cached. Fixed the second problem by reducing the search scope used to search for potential declarations of the declaring type to the project being investigated (excluding prereq projects)
