Bug 5916

Summary:	Search - too many matches for refs to NameLookup.findPackageFragmentRoot
Product:	[Eclipse Project] JDT	Reporter:	Philipe Mulet <philippe_mulet>
Component:	Core	Assignee:	Jerome Lanneluc <jerome_lanneluc>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	2.0
Target Milestone:	2.0 M1
Hardware:	PC
OS:	Windows 2000
Whiteboard:

Description Philipe Mulet

2001-11-14 12:57:43 EST

Build 20011107 + Jdtcore from HEAD (~v_212), self-hosting setup.

When searching for references to Namelookup.findPackageFragmentRoot(IPath), I 
obtained 5 matches, where only the last one is a correct one. The 4 previous 
ones are inaccurate ones. Project jdtui was in source.

?: checkNewName() - 
org.eclipse.jdt.internal.core.refactoring.rename.RenameSourceFolderRefactoring
?: chooseSourceContainer(IJavaElement) - 
org.eclipse.jdt.internal.ui.wizards.ContainerPage
?: exportElement(Object, IProgressMonitor) - 
org.eclipse.jdt.internal.ui.jarpackager.JarFileExportOperation
?: isOnBuildPath(IJavaProject, IJavaElement) - 
org.eclipse.jdt.internal.ui.util.JavaModelUtil
findPackageFragmentRoot(IPath) - org.eclipse.jdt.internal.core.JavaProject

Comment 1 Jerome Lanneluc

2001-11-16 04:58:04 EST

The test case is as follows:
Project P
  Source folder src1
    X.java
  Source folder src2
    X.java

Both X.java have references to method foo(). When searching for references to 
method foo(), P/src2/X.java appears as having an inaccurate match.

The problem is that P/src2/X.java is hidden by P/src1/X.java. It should not 
even be considered as a potential compilation unit.

Changed MatchLocator to sort the potential compilation units in the classpath 
order. This allows to detect hidden types by checking if there is a 
DuplicateTypes problem after bindings resolution. In this case, the potential 
compilation unit is skipped.