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

x/tools/gopls: show type errors in other files when the package contains syntax errors #32596

Closed
leitzler opened this issue Jun 13, 2019 · 6 comments
Labels
Milestone

Comments

@leitzler
Copy link
Contributor

@leitzler leitzler commented Jun 13, 2019

What version of Go are you using (go version)?

$ go version
go version go1.12.4 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
N/A

What did you do?

I've several times working with govim ran into the fact that an introduced syntax error in one of a package's go files stops diagnostics to be received for other go files inside the same package. Most recently my confusion resulted in an issue in the govim tracker, govim/govim#297.

As Paul pointed out in that issue, it might be a good idea for gopls to ignore the files that contains syntax errors and still process other files in the same packages.

What did you expect to see?

Diagnostics for all go files, in the same package, that doesn't contain a syntax error

What did you see instead?

Just the syntax error

@gopherbot gopherbot added this to the Unreleased milestone Jun 13, 2019
@gopherbot gopherbot added the gopls label Jun 13, 2019
@stamblerre stamblerre changed the title x/tools/gopls: package typecheck is interrupted by syntax errors x/tools/gopls: show type errors in other files when the package contains syntax errors Jun 13, 2019
@stamblerre

This comment has been minimized.

Copy link
Contributor

@stamblerre stamblerre commented Jun 13, 2019

Thanks for reporting. You're right - we only show syntax errors when a package contains them, but that can lead to confusing behavior. The solution to this would be to report only syntax errors in the file that contains them, while showing type errors in the other files.

@stamblerre stamblerre added the NeedsFix label Jun 13, 2019
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jun 14, 2019

Change https://golang.org/cl/182466 mentions this issue: internal/lsp: determine diagnostics to show per-file, not per-package

@muirdm

This comment has been minimized.

Copy link

@muirdm muirdm commented Jun 15, 2019

I can see the benefit of this change, but it also seems a bit weird. Since the package is the unit of type checking, you can't really trust the type checker results if there is a syntax error. You can get arbitrary false positive and false negative type checker errors in the package's other files due to the syntax error. For comparison, the compiler doesn't give any type errors if there are syntax errors.

Out of curiosity, why can't we also send type checker errors for the file with the syntax error as well? I assume most of the time the file mostly parses and mostly type checks just fine.

@leitzler

This comment has been minimized.

Copy link
Contributor Author

@leitzler leitzler commented Jun 15, 2019

Can you give examples of how a syntax error in one file could trigger false pos/neg type check errors in another?

I use vim, and if I for example have type check errors in several files in a package, they all show up in the error list. As vim gets diagnostics from gopls as I type, the list will be cleared of all errors if I start to declare a new func, and then be populated again when the syntax is complete.

That’s how it works from the user perspective, but I also understand if the package is the unit of type check.

@muirdm

This comment has been minimized.

Copy link

@muirdm muirdm commented Jun 15, 2019

A syntax error often renders all the following code un-type checkable, so false positives would be very common. For example, code in another file calls function foo(), but that function cannot be type checked because of the syntax error (so you get potentially confusing undeclared name: foo error in the other file). False negatives can happen for example if you have a duplicate method that doesn't get type checked due to the syntax error. You should get foo redeclared in this block in the other file, but you won't because of the syntax error.

I imagine this change will be useful on the whole, but I just wanted to point out it could lead to some confusing errors.

@stamblerre

This comment has been minimized.

Copy link
Contributor

@stamblerre stamblerre commented Jun 17, 2019

@muirrn, you're definitely right that this will lead to some issues. When you don't filter type errors if there is a syntax error, you get a huge amount of "fake" type errors. Maybe we can introduce this setting through an opt-in configuration first, just to make sure it doesn't cause problems?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.