go/types: improve error messages by using compact package names

[emil14]

What I'm going to talk about is probably related to Go compiler or something else at the lower level that VSCode, but I'm not sure. It would be great if someone could answer me and maybe move this issue to project where it should be.

Today I saw this message (from my working project):

cannot use &(controller literal) (value of type *controller) as apiaccess.Controller value in return statement:
wrong type for method GetAvailableServices
(have func(ctx context.Context, p gitlab.somecompany.net/project/internal/apiaccess.GetAvailableServicesParams) ([]gitlab.somecompany.net/project/internal/service.Service, error),
want func(ctx context.Context, p gitlab.somecompany.net/project/internal/apiaccess.GetAvailableServicesParams) (*[]gitlab.somecompany.net/project/internal/service.Service, error))

It's a lot :) And it's hard to read. While the actual information is just "missing * symbol in return statement"

First of all we could get rid of these long paths to variables which in my example starts with gitlab.somecompany.net/project. Maybe we can even drop all of the paths and write apiaccess.GetAvailableServicesParams vs gitlab.somecompany.net/project/internal/apiaccess.GetAvailableServicesParams. This is how it could look like:

cannot use &(controller literal) (value of type *controller) as apiaccess.Controller in return statement:
wrong type for method GetAvailableServices
(have func(ctx context.Context, p apiaccess.GetAvailableServicesParams) ([]service.Service, error),
want func(ctx context.Context, p apiaccess.GetAvailableServicesParams) (*[]service.Service, error))

Maybe we could drop paths only for current project (using the "module" value in go.mod)

And lastly I would like to share the perfect error message :) I know it's hard to implement and it's hardly relevant to VSCode but anyway

cannot use *controller as apiaccess.Controller in return statement:
wrong type for method GetAvailableServices ([]service.Service instead of *[]service.Service in return)

Thanks!

[stamblerre]

What version of Go are you using? Please try updating to 1.15, rebuild gopls (GO111MODULE=on go get golang.org/x/tools/gopls@latest) and let us know if the error message is any better. There should have been some error message improvements in 1.15.

[emil14]

@stamblerre I was using 1.14

I checked the 1.15 and error messages are really somewhat better :)

[stamblerre]

Glad to hear it. I think we want to keep go/types error messages consistent with those produced by the compiler.
Does the compiler produce better output?

/cc @findleyr