This may be a vim issue rather than one with gopls. The gopls syntax error message says that it is a diagnostic for p.go in its "uri" field. (at least when I try your example)

gopls looks at p.go because it runs go/packages.Load ./... (that is, on the whole module) to report errors that would stop the module from compiling, I think.

This may be a vim issue rather than one with gopls

I don't think so.

I raised this issue because the diagnostics returned by gopls don't carry with them any dependency information.

This isn't about me being able to filter to show only the main.go diagnostics; it's about being able to filter the list of diagnostics to only show the diagnostics for package main and its transitive dependencies.

And by extension we might also want to show diagnostic errors for reverse dependencies too, filtering out anything else.

But without this information being sent by gopls we can't do any filtering in govim/Vim/elsewhere.

Can you share the gopls log that you're seeing for this example? The diagnostics I get are:

[Trace - 14:48:07.106 PM] Received notification 'textDocument/publishDiagnostics'.
Params: {"uri":"file:///[redacted]/p/p.go","diagnostics":[{"range":{"start":{"line":2,"character":0},"end":{"line":2,"character":0}},"severity":1,"source":"syntax","message":"expected declaration, found asdf"}]}

which make it clear that the error is not in main.go.

The diagnostics I get are:

That's exactly what I see as well.

which make it clear that the error is not in main.go.

Indeed.

But we can't programmatically filter out that diagnostic in govim/Vim because we can't know that it's not in the transitive dependencies of package main.

What I'm imagining here is three modes of showing diagnostics in the quickfix window in Vim:

1. show all diagnostics sent by gopls
2. show diagnostics for the current file's package and its transitive dependencies
3. show diagnostics for the current file's package, its transitive dependencies, and reverse dependencies of the current file's package

Because if there are errors, like in package p, that are not relevant to the file/package I'm working on (main in this example) then I can't easily tell when I'm "done". I often use "zero diagnostics" as an indicator that I'm good to test (the current package).

How would this work in the context of LSP publishDiagnostics message? A diagnostic has to be associated with a specific file, so I'm not sure how it would be possible to show diagnostics in a way that makes it clear that they apply to a reverse dependency or something like that.

How would this work in the context of LSP publishDiagnostics message

That's exactly the reason for me raising this issue. gopls (now) always sends diagnostics for the entire workspace: given the current LSP spec, we currently have no means by which we can filter diagnostics that are shown to the user based on some context i.e. visible file(s).

This sounds like a specifically terminal-based editor issue. In VS Code, all diagnostics are associated with a file and diagnostics are shown for the whole workspace, so you are able to see which diagnostics belong to which file by looking in the file explorer tab on the left or through the "Problems" pane. I expect most people keep working until their entire workspace builds. In Vim, I see how this might be an issue since you don't have similar navigation tools. I would recommend looking into how other LSP clients handle this.

The closest thing that LSP has for this is the "Related Information" in the diagnostic, but that's not exactly what you mean (I think). To me, it sounds like you are looking for additional configuration in gopls that changes the scope of the diagnostics sent. It's similar to what people have requested for diagnostics that are only sent on save. In those cases, we have suggested that the configuration ought to live client-side. I understand why it would require a lot of additional work in govim to figure out dependencies and reverse dependencies for packages, but I'm not convinced that this use case is significant enough to justify additional complexity in gopls. If this is an issue that users report naturally, I'd be happy to consider it again, but the example you've given seems artificial to me.

At this point, we've migrated to diagnosing the user's entire workspace on every file change. I don't think we will move from this approach or add additional configuration for it in the near future, and the additional complexity does not seem worth the benefit to me. Closing this issue as a result.

If this is an issue that users report naturally, I'd be happy to consider it again, but the example you've given seems artificial to me.

I am one such user providing feedback! Admittedly just one, but a user nonetheless 😄

To me, it sounds like you are looking for additional configuration in gopls that changes the scope
of the diagnostics sent.

I'm actually discussing/suggesting something different. But it's not high priority, so not worth us spending time on now.