Bug 3210 - Search - method declarations within TypeHierarchy gives no matches (1G54BMR)
Summary: Search - method declarations within TypeHierarchy gives no matches (1G54BMR)
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: All Windows NT
: P3 normal (vote)
Target Milestone: 2.0 M3   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-10-10 22:51 EDT by Dani Megert CLA
Modified: 2002-02-01 13:14 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dani Megert CLA 2001-10-10 22:51:21 EDT
DM (11/28/00 11:09:12 AM)
	0. Start Eclipse (no workspace)
	1. Create solution and Java project with JUnit
	2. Open search view to prevent exception (known bug when working in IDE)
	3. Open junit.tests.AllTests (from JUnit) and select suite() in the Outline.
	4. Choose "Declarations" in the context menu (IMPORTANT: Use "Declarations in Hierarchy" if available)
	==> no search result

	The declaration search uses com.ibm.jdt.core.search.HierarchyScope.
	It works when the search is performed via context menu in the type hierarchy.
	BUT: When using a binary type (e.g. java.awt.CardLayout) the search does also
			not work when performed via hierarchy view.

	SOURCE CASE: In both cases the type to create a new HierarchyScope is
	com.ibm.jdt.core.SourceType (id=1869). I guess the problem its parent:
	in case of the Outline it is com.ibm.jdt.core.WorkingCopy (id=1873)

	BINARY CASE: the type is com.ibm.jdt.core.BinaryType
	with com.ibm.jdt.core.ClassFile as parent

PM (11/28/00 1:30:02 PM)
	Might be related to the fact our JavaElement declaration queries are too accurate (only find the matches on the same declaring type, i.e. the
	one you already have).

JBL (11/29/00 4:50:17 PM)
	Actually the problem is that we fail when finding out that the type hierarchy scope encloses the indexed file.

JBL (11/30/00 6:13:34 PM)
	Fixed the binary case. 
	The source case still doesn't work because the hierarchy scope is created on a working copy. Need to investigate more.

JBL (12/4/00 3:29:53 PM)
	Jabiru 28 doesn't use hierarchy scope when searching from the context menu any longer.
	Is it ok to close?

DM (12/5/00 8:37:38 AM)
	No.
	Why do you think that it doesn't use hierarchy scope? If it doesn't then its my bug.
	In our (ZRH) version of Jabiru 28 are 2 context menus	(in the Outline and in the
	Type Hierarchy view):
		Declarations						(should use workbench scope)
		Declarations in Hierarchy	(should use type hierarchy scope)

JBL (12/5/00 10:45:43 AM)
	I'm saying it doesn't use the hierarchy scope because when I put a breakpoint in 
	SearchEngine.search(IWorkbench, IJavaElement, int, IJavaSearchScope, IJavaSearchResult)
	and I use Declarations in Hierarchy, then the scope is a JavaWorkbenchScope not a
	HierarchyScope.

JBL (12/5/00 10:48:14 AM)
	If you decide to put the hierarchy scope back, you should not pass an IType from a working copy
	but the IType from the compilation unit as the TypeHierarchyViewPart does.
	i.e.
		ICompilationUnit cu= type.getCompilationUnit();
		if (cu != null && cu.isWorkingCopy()) {
			type= (IType)cu.getOriginal(type);
		}

JBL (12/5/00 11:06:48 AM)
	Also note that if you pass an IJavaElement to the search engine in the case of Declarations (in workbench)
	you will get the exact same results as in the case of Declarations in Hierarchy. If the semantic you want in the
	first case is "all declarations with the same name", then you should use 
	search(IWorkbench, String, int, int, IJavaSearchScope, IJavaSearchResultCollector)

DM (12/5/00 5:31:48 PM)
	I agree that the type is not handled correctly by the UI - filed a PR. However, this
	PR is about a method and not a type. What you say (i.e. the JavaElement API being called for search)
	is related to types and not to the method search. In the method search I use the string pattern API to search.
	If you put a breakpoint in the "stringPattern" API and repeat the test case you will see that I use the following scopes:
		JavaWorkbenchScope		for	Declarations
		HierarchyScope					for 	Declarations in Hierarchy
	I guess it is not the search that is wrong. I guess the API to construct a HierarchyScope returns a scope which seems
	not to work.

JBL (12/5/00 12:05:26 PM)
	I'm sorry. I misread this PR. I was able to reproduce the problem and I will look at it.

JBL (12/5/00 12:14:46 PM)
	In fact the problem with method declarations in a hierarchy scope is the same as type declarations in a hiearchy scope:
	if the hierarchy scope is created on a type in a working copy, then it won't work. I will change the constructor of the
	hiearchy scope to not allow it to be created on a type in a working copy.

DM (12/5/00 6:33:11 PM)
	Couldn't the creator be smart enough to execute the code you mentioned:
		ICompilationUnit cu= type.getCompilationUnit();
			if (cu != null && cu.isWorkingCopy()) {
				type= (IType)cu.getOriginal(type);
			}

JBL (12/5/00 3:17:12 PM)
	I wanted to let the UI do it to give it a chance to tell the user that he was searching from a working copy and the result
	would be in a compilation unit. For example, if the user creates a compilation unit A.java and he/she modifies its content
	to be:
	public class A {
		void foo() {
		}
	}
	class B extends A {
		void foo() {
		}
	}
	without saving it. Then if he/she searches for declarations of foo() in the hierarchy, there would be no match. That could
	be interpreted as a bug.

DM (12/6/00 9:32:27 AM)
	I agree if you/the search engine give me that feeling/API (exception for working copies) but then
	I also want it when I do a search for a JavaElement that is a working copy - not only if I want to
	create a hierarchy (i.e. the whole search API has to conform to your new definition).
	I rather like working copies to be handled by the search engine because even if the input is
	a working copy I still want to search for the references to it or for all its declarations (no matter
	if the content in the editor has been changed or not). Furthermore the problem you describe
	remains because I can search for a text pattern and there I will also not get support by the
	search engine.
	Please note that one part of the PR is against a binary element which is read-only:
		When using a binary type (e.g. java.awt.CardLayout) the search does also
		not work when performed via hierarchy view.

JBL (12/6/00 11:06:58 AM)
	I agree with you for the working copy case. All I was saying was that for now this doesn't work and it would
	be good if you could workaround the problem on your side.
	For the binary case, I just verified that it is fixed. Do you still have the problem with build 0.014a?

DM (12/6/00 6:34:58 PM)
	Binary case verified: OK.
	No problem, I can put the workaround in the UI code until it is fixed.

DM (12/7/00 9:38:10 AM)
	Added above code to a workaround (Jabiru > 28) in:
		IBM Java Base UI [28.20 dm]
			com.ibm.jdt.ui.search [28.20 dm]
				FindHierarchyDeclarationsAction.java [28.20 dm]

JBL (6/18/2001 2:30:50 PM)
	Need to ensure that a hierarchy scope can be created on a working copy.
Comment 1 DJ Houghton CLA 2001-10-23 23:51:39 EDT
PRODUCT VERSION:
	Eclipse 013+, VAME, JDK 1.2.2


Comment 2 Jerome Lanneluc CLA 2002-02-01 10:57:57 EST
Added support to allow the creation of a hierarchy scope on a type coming from 
a working copy.