Bug 163072

Summary:

[search] method reference reports wrong potential matches

Product:

[Eclipse Project] JDT

Reporter:

Markus Keller <markus.kell.r>

Component:

Core

Assignee:

Frederic Fusier <frederic_fusier>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

Version:

3.3

Target Milestone:

3.3 M4

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
Proposed patch	none

Description Markus Keller

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

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

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

2006-11-06 09:18:57 EST

Created attachment 53294 [details]
Proposed patch

Comment 4 Frederic Fusier

2006-11-06 09:25:15 EST

Released for 3.3 M4 in HEAD stream

Comment 5 David Audel

2006-12-12 04:58:28 EST

Verified for 3.3M4 with I20061212-0010.