Community
Participate
Working Groups
Build 20020618 1. Create a jar with the following class: public class X { void foo() { class Y {} System.out.println(new Y().toString()); } } 2. Add jar to build path and attach source 3. Open X$1$Y.class 4. Select Y in Outline and search for type declaration Observe: None is found.
Problem seems to be with the creation of the TypeDeclarationPattern: it creates a pattern that says the type name should be Y (correct) with no enclosing types (incorrect). Change would require to read the class file to find out that it is a local type. This is too much of a change. Propose to defer post 2.0.
Another failing test case: Search doesn't find any type declaration for Y in: public class X { class M { void foo() { class Y { } } } }
Along the line of bug 20532, we have search issues with binary nested types (20532 takes care of members, this bug covers local types). Search in binaries is a 2.0 addition, so we want to address defects in this area. Need to come up with a fix really soon for having it in for F4.
When traversing the ast to report the matches, in a method we first report the references, then the declarations. The local type declaration is found as a reference and could not be reported, so it is lost. We should first report the declarations then the remaining nodes are references. Proposed fix (in MatchSet): /** * Visit the given method declaration and report the nodes that match exactly the * search pattern (ie. the ones in the matching nodes set) * Note that the method declaration has already been checked. */ private void reportMatching(AbstractMethodDeclaration method, IJavaElement parent) throws CoreException { // declaration in this method // (NB: declarations must be searched first (see bug 20631 Declaration of local binary type not found) if ((method.bits & AstNode.HasLocalTypeMASK) != 0) { LocalDeclarationVisitor localDeclarationVisitor = new LocalDeclarationVisitor(); localDeclarationVisitor.enclosingElement = (parent instanceof IType) ? this.locator.createMethodHandle(method, (IType) parent) : parent; try { method.traverse(localDeclarationVisitor, (ClassScope) null); } catch (WrappedCoreException e) { throw e.coreException; } } // references in this method AstNode[] nodes = this.matchingNodes(method.declarationSourceStart, method.declarationSourceEnd); for (int i = 0; i < nodes.length; i++) { AstNode node = nodes[i]; Integer level = (Integer)this.matchingNodes.get(node); if ((this.matchContainer & SearchPattern.METHOD) != 0) { this.locator.reportReference( node, method, parent, level.intValue() == SearchPattern.ACCURATE_MATCH ? IJavaSearchResultCollector.EXACT_MATCH : IJavaSearchResultCollector.POTENTIAL_MATCH); this.matchingNodes.remove(node); } } if (this.potentialMatchingNodes(method.declarationSourceStart, method.declarationSourceEnd).length == 0) { // no need to resolve the statements in the method method.statements = null; } }
Not critical enough for considering for 2.0 (nobody but us found it, and fix is not trivial). Deferring, fix needs to be tested
Added proposed fix, plus a change on LocalDeclarationVisitor so as to report local type declaration when one is found. Added regression test.
Verified.
