x/tools/gopls: completion gives unneeded generic type instantiation snippet

[muirdm]

func foo[T float64 | int](a T) T {
	return a
}

func main() {
	var _ int = fo<>
}

Completing to "foo" at <> inserts "int(foo[T float64|int](a T))" (ignore the extra type conversion), but most likely the type argument can be inferred so gopls should offer just "foo(a int)" instead.

[muirdm]

Would this work: if there is one type param and it is the func’s return type and one of the variants is assignable to the expected type (int in this case), then presume type inference will work and omit the instantiating snippet? Is there any programmatic interface to check type param inference?

I guess it is more question of "will type inference work for this function call", and if "yes" then don't give the type param snippet. If go/types can't tell us that, then I feel like some simple heuristics can cover common cases. For example, if all the type params are referenced in the param list, then type inference will work (is that correct?).

[muirdm]

@findleyr Can we hook in to type param inference to determine a priori if a generic function's type params will/might be inferable after the normal params are filled in? I know sometimes it depends on the arguments, but my feeling is that type param inference works most of the time if it can work at all for a given function.

In a similar vein, the heuristic I suggested above would not work in all cases, but I think it would be an improvement (i.e. if type inference will "probably" work, don't give the type param snippet).