Duplicate of #38230

This has the same root cause as the above issue, and it will be fixed by https://golang.org/cl/229319/.

Duplicate of #38230

Apologies. Thanks for linking.

I see that #38230 has now been closed, which fixes part of the problem raised in this issue. Specifically it now correctly qualifies the parameter so the label appears as:

Instances(args []string, c *load.Config) []*build.Instance

But this still leaves the question about the return value not being qualified.

This is doable, but I wonder if it may be bad UX. Of course the test case I came up with is pathological, but it was basically this:

-- testy/testy.go --
package testy

import (
	"golang.org/x/tools/internal/lsp/snippets"
)

func _() {
	snippets.X()
}
-- snippets/snippets.go --
package snippets

import (
	"golang.org/x/tools/internal/lsp/signature"
	"golang.org/x/tools/internal/lsp/types"
)

func X(_ map[signature.Alias]types.CoolAlias) map[signatures.Alias]types.CoolAlias) {
	return nil
}

Then, the signature help for X is X(_ map[golang.org/x/tools/internal/lsp/signature.Alias]golang.org/x/tools/internal/lsp/types.CoolAlias) map[golang.org/x/tools/internal/lsp/signatures.Alias]golang.org/x/tools/internal/lsp/types.CoolAlias).

I'd be curious to get @heschik's thoughts on this.

A note on how to do implement this: We'd have to check package names for any *ast.SelectorExprs we come across in qualifyExpr.

I wonder if it may be bad UX

I definitely share this concern. But whenever you come across a situation like this it's always jarring if the package is not imported by the current file.

IMO, if there's a problem here fully qualifying the path is not the right solution. If you're familiar with the API, the full path is just going to be an impediment to readability. If you're not, then the full path is not going to be enough to teach you how to use it.

What is the actual use case?

Change https://golang.org/cl/229979 mentions this issue: internal/lsp: handle different package names in signature help

Just mailed a CL that handles a few edge cases, but I agree that the use case is not clearly defined. I think that we should leave this as-is for now, and if this is something that many users bring up, we can address it then. I'm not sure that the benefits of being more precise outweigh the readability costs here.

Closing this since the edge cases have been handled, and we're planning to leave unimported package paths as-is.