Bug 26611 Code completion assumes multiple args of same type will take same value
Build 20021115 (M3) 1) Start with the following JCU: public abstract class A { private int fieldInt = 5; public void foo(int a, int b, int c) { } public void bar() { int integer = 5; fo<cursor-is-here> } } 2) Invoke code assist at the cursor position indicated above 3) From the list of completions, select the method foo -> It guesses the parameter values, and highlights and underlines the first value, "integer". So far so good. 4) Type "fieldInt" as the first parameter value. -> It replaces all three parameters with the value "fieldInt". Not expected, but fine. 5) Hit tab to accept the guess for the first parameter. -> The cursor goes to the end of the line. What I expect: The method "foo" has three distinct parameters. I would expect to have to hit tab three times, once for each parameter. This template assumes that there is only one variable to complete, and that all three parameters of type "int" will have the same value.
org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/text/java/ParameterGuesser.java
* @param paramPackage - the package of the parameter we are trying to match
	 * @param paramType - the qualified name of the parameter we are trying to match
	 * @param paramName - the name of the paramater (used to find similarly named matches)
	 * @return returns the name of the best match, or <code>null</code> if no match found
	 */
	public String guessParameterName(String paramPackage, String paramType, String paramName) throws JavaModelException {
		
		if (fVariables == null) {
			VariableCollector variableCollector= new VariableCollector();
			fVariables= variableCollector.collect(fCodeAssistOffset, fCompilationUnit);
		}
		
		List typeMatches= findFieldsMatchingType(fVariables, paramPackage, paramType);
		return chooseBestMatch(typeMatches, paramName);
	}
	
	/**
	 * Determine the best match of all possible type matches.  The input into this method is all 
	 * possible completions that match the type of the argument. The purpose of this method is to
	 * choose among them based on the following simple rules:
	 * 
	 * 	1) Local Variables > Instance/Class Variables > Inherited Instance/Class Variables
	 * 
	 * 	2) A longer case insensitive substring match will prevail
	 * 
	 * 	3) A better source position score will prevail (the declaration point of the variable, or
	 * 		"how close to the point of completion?"
	 * 
	 *  4) Variables that have not been used already during this completion will prevail over 
	 * 		those that have already been used (this avoids the same String/int/char from being passed