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.

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

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.

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.

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.

@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?