Bug 5916 - Search - too many matches for refs to NameLookup.findPackageFragmentRoot
Summary: Search - too many matches for refs to NameLookup.findPackageFragmentRoot
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 2.0 M1   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-11-14 12:57 EST by Philipe Mulet CLA
Modified: 2002-01-11 09:22 EST (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Philipe Mulet CLA 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 CLA 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.