Bug 163072 - [search] method reference reports wrong potential matches
Summary: [search] method reference reports wrong potential matches
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.3 M4   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-01 10:18 EST by Markus Keller CLA
Modified: 2006-12-12 04:58 EST (History)
0 users

See Also:


Attachments
Proposed patch (4.48 KB, patch)
2006-11-06 09:18 EST, Frederic Fusier CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2006-11-01 10:18:07 EST
I20061031-0656

Search for method reference reports wrong potential matches.

Steps:
- new workspace
- plug-ins in source:
org.eclipse.jdt.apt.core
org.eclipse.jdt.apt.ui
org.eclipse.jdt.core
- all required plug-ins imported as binary plug-ins
- search for references to org.eclipse.jdt.core.search.TypeNameMatch.getType()

=> Among the correct matches, I get wrong potential matches in the apt.ui plug-in, e.g. in AdvancedFactoryPathOptionsDialog.createDialogArea(Composite).
Comment 1 Frederic Fusier CLA 2006-11-02 12:20:37 EST
Message send binding is not fully resolved due to the fact that units which contain possible match are parsed and resolved per project without taking account of their dependencies.

The false matches are found in org.eclipse.jdt.apt.ui project and the receiver type is FactoryContainer is defined in org.eclipse.jdt.apt.core dependent project. The type is so considered as unresolved and match is wrongly returned as potential...

MatchLocator in #locateMatches(SearchDocument[]) needs to be a little bit smarter a not split units in dependent projects...
Comment 2 Frederic Fusier CLA 2006-11-06 06:25:41 EST
Hmm... It's really more subtle than that... Problem came from basicParser of MatchLocator! This parser is lazy initialized only once although it should be reset while initializing MatchLocator for each project...

In the failing example, the basicParser was initialized with org.eclipse.jdt.core project which compliance is 1.4. So, when parsing compilation units found in apt projects, 1.4 compliance is still use and so each of them have compilation errors => potential match on some of them...

Here's a simpler example:
P1 (1.4 compliance)
  src
    test
      Test.java
        package test;
        public class Test {
	    public Object getType() {
		return null;
	    }
	    public void foo() {
		if (getType() == null) {
			System.out.println("null");
		}
	    }
        }

P2 (compliance 1.5, depends on P1)
  src
    pack
      FactoryContainer.java
	package pack;
	public class FactoryContainer {
	    public enum FactoryType { PLUGIN }
	    public FactoryType getType() {
		return FactoryType.PLUGIN;
	    }
	}
      Reference.java
	package pack;
	public class Reference {
	    private final FactoryContainer _fc;
	    public Reference() {
		_fc = new FactoryContainer();
	    }
	    boolean foo() {
		return_fc.getType() == FactoryContainer.FactoryType.PLUGIN;
	    }
	}

Search for reference of Test.getType() method and then you'll find a potential match in Reference.foo() method...
Comment 3 Frederic Fusier CLA 2006-11-06 09:18:57 EST
Created attachment 53294 [details]
Proposed patch
Comment 4 Frederic Fusier CLA 2006-11-06 09:25:15 EST
Released for 3.3 M4 in HEAD stream
Comment 5 David Audel CLA 2006-12-12 04:58:28 EST
Verified for 3.3M4 with I20061212-0010.