Comment 1 Martin Aeschlimann 2005-11-16 19:01:16 EST

Could reproduce with 3.2 M3.

The AST makes a guess for the reference of 'm' in a.a(). But it chooses
m(String) instead of the better suited m(int, String)

This is the same as bug 69471 which doesn't seem to be fixed. Moving to jdt.core

Comment 2 Kent Johnson 2005-11-17 11:48:08 EST

Martin, how does the UI make this case work:

class Y {
	Y(int x, String y) {}
	Y(String x) {}
	Y(boolean x, String y, String z) {}
	void test() {
		new Y(first, second);
	}
}

You have no binding for the constructor, and we never even try to find a 
matching constructor, but the UI still finds the best guess.

So why don't you do the same thing for this case:

class X {
	void m(int x, String y) {}
	void m(String x) {}
	void m(boolean x, String y, String z) {}
	void test() {
		m(first, second);
	}
}

Comment 3 Kent Johnson 2005-11-17 11:51:06 EST

Martin, the UI algorithm seems to be off with this case:

public class Y {
	Y(int x, String y) {}
	Y(String x) {}
	Y(boolean x, Object y, String z) {}
	void test(boolean first) {		
		new Y(first, second);
	}
}

It thinks second should be a String, not Object.

Comment 4 Martin Aeschlimann 2005-11-18 03:58:50 EST

I started doing my own guessing for constructors ( a long time ago) because
there we get no bindings at all. For methods there were guessings from the
beginning which I think are also used by the compiler itself e.g. for hovers and
for the error messages.

Idealy, the AST would give the bindings for both method and constructors, as
good as possible. In my opinion, the number of parameters should always be
looked at first. But of course, you could also argue that a the match of a first
parameter is to be considered as well. 

Comment 5 Kent Johnson 2005-11-18 15:27:21 EST

Martin, I released changes to both method & constructor lookup.

Please check with the UI behaviour to see if/when 'your best guess' can be 
turned off.

Comment 6 Martin Aeschlimann 2005-11-21 15:17:12 EST

Sorry, still found a problem:
public class Z {
	void foo(boolean x, String y, String z) {}   // (a)
	void foo(int x, String y) {}                 // (b)
	void foo(String x, String y) {}              // (c)
	void foo(String x) {
        foo(first, "second");   // maps to (a) should be (c)
        foo(first, second);     // maps to (b) ok
        foo(true, second);      // maps to (a) ok
}

It also doesn't seem ot work for the constructors yet. Maybe you have to enable it for the DOM AST?

class Y {
	Y(boolean x, String y, String z) {}
	Y(int x, String y) {}
	Y(String x) {
		this(first, second);
	}

	void test() {
		new Y(first, second);
	}
	
	class Z extends Y {
		public Z() {
			super(first, second);
		}
	} 

Comment 7 Kent Johnson 2005-11-21 15:25:05 EST

Olivier, can you take a look to see if the DOM needs to do something in this case?

Comment 8 Olivier Thomann 2005-11-23 16:13:29 EST

public class Z {
        void foo(boolean x, String y, String z) {}   // (a)
        void foo(int x, String y) {}                 // (b)
        void foo(String x, String y) {}              // (c)
        void foo(String x) {
        foo(first, "second");   // maps to (a) should be (c)
        foo(first, second);     // maps to (b) ok
        foo(true, second);      // maps to (a) ok
}

For foo(first, "second"); // maps to (a) should be (c)
I don't see why it should map to (c). It could map to either (b) or (c). And there is no way to find out which one is the best match.
Kent, for now we do map it to (a) which looks strange.

The constructor's bindings are null. So no matching is performed. I'll check the conversion to see if we need to do anything.

Comment 9 Martin Aeschlimann 2005-11-24 03:54:28 EST

Agree, should be (b) or (c), but not (a).

Releated question: Is code resolve using these guesses as well? It would be nice to have code resolve working for contructors with errors.

Comment 10 Kent Johnson 2005-11-24 14:41:01 EST

Enabled the test ASTConverterTestAST3_2

Released changes into HEAD

Comment 11 Olivier Thomann 2005-11-24 18:53:01 EST

I verified that this works as expected for the submitted test cases.
Martin, please double-check that all cases are covered.

Comment 12 Martin Aeschlimann 2005-11-25 03:57:45 EST

verified, removed the workaround code in jdt.ui > 20051125

Comment 13 Olivier Thomann 2006-04-21 13:40:16 EDT

*** Bug 138010 has been marked as a duplicate of this bug. ***