Summary: | Declaration of local binary type not found | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Jerome Lanneluc <jerome_lanneluc> |
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | ||
Version: | 2.0 | ||
Target Milestone: | 2.1 M1 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Jerome Lanneluc
2002-06-19 07:46:15 EDT
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. |