Community
Participate
Working Groups
Build 20020611 - Open java perspective - Import all plugins to your workspace - Go to Search->Java... - Type in "Label", and select Type, Declarations, and Workspace, click Search In the search results, one of the results is: "Label - org.eclipse.ui.dialogs.FilteredList.Label" This is an inner class. The icon for this one is a little red square, and double clicking on it to open it causes it to say: "Could not open the editor. Reason: FilteredList$Label$Label.class does not exist." Notice how it's looking for two nested "$Label".. and how in the search results it appends ".Label" at the end of the entry. Other search results don't append the class name, such as the following: "Label - org.eclipse.swt.widgets" <-- no ".Label" at the end
This also adds to the .log
should investigate in a fix
*** This bug has been marked as a duplicate of 19993 ***
reopen - accidently tagged as a dup
Investigated. The match reported by J Core is unusable: the class file of the binary type is wrong (see attached picture for more details). This might affect other clients of the J Search infrastructure.
Created attachment 1472 [details] Picture of Variables view
Problem with MatchLocator that creates a member type handle when the type handle of the class file should be used in case of a binary type. Propose fix on MatchLocator: /** * Reports the given type declaration to the search requestor. */ public void reportTypeDeclaration( TypeDeclaration typeDeclaration, IJavaElement parent, int accuracy) throws CoreException { // accept class or interface declaration this.report( typeDeclaration.sourceStart, typeDeclaration.sourceEnd, (parent == null) ? this.createTypeHandle(typeDeclaration.name) : (parent instanceof IType && !(parent instanceof BinaryType)) ? this.createTypeHandle((IType)parent, typeDeclaration.name) : parent, accuracy); }
Please verify fix for local type members.
Indeed the declaration of a local binary type is not found. Need to investigate.
If we get a fix for F4, we should fix it. Search works ok, only Java element creation is deficient, and prevents exploiting the search result.
For local binary types, the problem is different: the type declaration pattern is not right. Entered separate bug 20631.
So the above change fixes the case of reporting the result of a binary member type declaration. It would also fix the case of reporting the result of a binary local type declaration, but bug 20631 prevents it to go that far. To summarize, the above change should go in F4 as it prevents to display wrong results when the search engine find some. It is a simple fix that affects only type declarations in binary types.
I actually have a better fix. Instead of the above change, I propose the following method that now first creates the top-level type handle of a binary type. Thus when traversing the member types, the right member type handles are created from the top-level type handle: /** * Creates an IType from the given simple top level type name. */ public IType createTypeHandle(char[] simpleTypeName) { Openable currentOpenable = this.getCurrentOpenable(); if (currentOpenable instanceof CompilationUnit) { // creates compilation unit CompilationUnit unit = (CompilationUnit)currentOpenable; // create type return unit.getType(new String(simpleTypeName)); } else { IType type; try { type = ((org.eclipse.jdt.internal.core.ClassFile)currentOpenable).getType(); } catch (JavaModelException e) { return null; } // ensure this is a top level type (see bug 20011 Searching for Inner Classes gives bad search results) IType declaringType = type.getDeclaringType(); while (declaringType != null) { type = declaringType; declaringType = type.getDeclaringType(); } return type; } }
This problem does not exists in 1.0.
This defect is not a duplicate of bug 20532, which wasn't finding matches at all. This one defect is rather an issue when constructing the search result. The generated handle (pointing at the enclosing element) is invalid, and thus cannot be opened.
From Adam, regarding to refactoring test suites: our tests run smoothly i activated the prevously disabled tests for 20693 Finding references to variables does not find all occurances 20520 Refactor - expression detection incorrect
Fix got approved, releasing into 20020621
Verified.
