Signature help does not display all overloaded methods

[hopehadfield]

In the case that a method contains less parameters in a superclass than the respective extended method in a subclass, all overloaded methods further extended from the superclass are not displayed in signature help. See the below example.

public class MovingObject {
    public void speed(int x, int y, int z){}
}

public class Vehicle extends MovingObject{
    public void speed(){}
}

public class Car extends Vehicle{
    public void speed(int x){}
    public void speed(int x, int y){}
}

There should be 4 overloaded methods displayed in signature help, but instead only the methods from Vehicle and MovingObject are visible.

[rgrunber]

Seems slightly similar to what @snjeza reported in #2014 (comment) . It's worth checking if the calls to completion return all the overloads, and if so, we should be able to figure out why signature help isn't displaying all of them.

[rgrunber]

The problem is here :

eclipse.jdt.ls/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/SignatureHelpContext.java

Lines 361 to 366 in 3c531fa

	while (declaringType != null) {
	String unqualifiedName = declaringType.getErasure().getName().replace(";", "");
	typeNames.add(unqualifiedName);
	declaringType = declaringType.getSuperclass();
	}
	this.declaringTypeNames = typeNames;

We get the declaring type based on the specific method that is selected (eg. for test.speed(), even though test is a Car, speed() is declared in Vehicle. From there we only discover the super classes of Vehicle, which are MovingObject, and java.lang.Object. Once we get to :

eclipse.jdt.ls/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/contentassist/SignatureHelpRequestor.java

Lines 119 to 140 in 3c531fa

	public void accept(CompletionProposal proposal) {
	if (!isIgnored(proposal.getKind())) {
	if (proposal.getKind() == CompletionProposal.METHOD_REF && !Objects.equals(proposal.getName() == null ? null : new String(proposal.getName()), methodName)) {
	return;
	}
	if (this.declaringTypeNames != null) {
	char[] declarationSignature = proposal.getDeclarationSignature();
	if (declarationSignature != null) {
	String proposalTypeSimpleName = SignatureHelpUtils.getSimpleTypeName(String.valueOf(declarationSignature));
	for (String typeName : this.declaringTypeNames) {
	String declaringTypeSimpleName = Signature.getSimpleName(typeName);
	if (Objects.equals(proposalTypeSimpleName, declaringTypeSimpleName)) {
	proposals.putIfAbsent(String.valueOf(proposal.getSignature()), proposal);
	return;
	}
	}
	return;
	}
	}
	proposals.putIfAbsent(String.valueOf(proposal.getSignature()), proposal);
	}
	}

we do get speed(int), speed(int, int) from the completion engine, but we dismiss them because Car is not in declaringTypeNames.

I think we need to revisit this logic because it is definitely broken. The name comparison is there because completion invocation within the parameter "area" was always a bit buggy and we had to dismiss some odd values, but computing subtypes (in addition to supertypes) could get expensive. Do we need to compute the types at all or can we just go by the rule of "accept any method whose name matches".

[rgrunber]

As a note the following is now an issue for signature help :

Test.java

package test1;

public class Test {

    public String[] getQuestions(boolean onlyMultipleChoice) {
        return null;
    }

    public String[] getQuestions() {
        return null;
    }
}

Exam.java

package test1;

public class Exam extends Test {

    public String[] getQuestions(int number) {
        return null;
    }
}

Main.java

package test1;

public class Main {
    public void doStuff() {
        Test ex = new Test();
        ((Exam) ex).getQuestions(|)
    }

    public String[] getQuestions(int number, String section, boolean multiple) {
        return null;
    }
}

It's an improvement over the issue of missing overloads.

[jdneo]

As a note the following is now an issue for signature help

Ah, that might be the reason why declaring type is preserved. Let's file an issue first.