Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
emil14 opened this issue Aug 26, 2020 · 3 comments
Open

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

emil14 opened this issue Aug 26, 2020 · 3 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone
Backlog

Comments

@emil14
Copy link

emil14 commented Aug 26, 2020

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!
@hyangah hyangah changed the title Improve error messages go/types: improve error messages by using compact package names Aug 26, 2020
@hyangah hyangah transferred this issue from golang/vscode-go Aug 26, 2020
@stamblerre
Copy link
Contributor

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.

@cagedmantis cagedmantis added Tools This label describes issues relating to any tools in the x/tools repository. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Aug 26, 2020
@cagedmantis cagedmantis added this to the Backlog milestone Aug 26, 2020
@emil14
Copy link
Author

emil14 commented Aug 26, 2020

@stamblerre I was using 1.14

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

@stamblerre
Copy link
Contributor

stamblerre commented Aug 26, 2020 •
edited

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

@findleyr findleyr mentioned this issue Dec 22, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
3 participants
@cagedmantis @stamblerre @emil14