The current behavior is correct (or rather, it's the best we can do). Per the spec, function bodies are optional in go code. The way I think of it is: it's not an error until you try to link, and with go:linkname directives (or other linker interventions) we can't know whether or not that function will be linked correctly.

Put differently, if we did this there would be thousands of errors in the Go standard library, and IIUC we have no practical way of identifying which missing function bodies are missing by accident.

By contrast, generic functions and init functions do require a function body, and gopls correctly reports an error in these cases.

Closing as I don't think we can do anything here. Please correct me if I'm wrong.

The current behavior is correct

For some definition of "correct" 😄

From the perspective of someone writing a Go program using gopls, it is not correct if my goal is to have all errors surfaced in my editor. Because the reality is that I cannot otherwise say "I am done with all the errors in my editor, let me now run my program". Perhaps a good analogy here is the go:embed directives: if errors related to these directives were not surfaced by gopls, then I feel we would be having the same discussion. But they are so we are not, and from my perspective as a user of gopls that is "correct". Just as link errors not being surfaced are not present, hence this issue.

However, this again comes back to the point of "what am I trying to do with gopls in this instance". In the case of this issue, I'm trying to get to a state where I can run the main program. I realise that we don't have a mechanism of support the description of such intentions, but again I wouldn't call this "correct".

So whilst it might internally be "correct" to not report errors in this situation, I'm not sure I agree that it is "correct" from the perspective of a gopls user, where the raison d'être of gopls is to help me fix my code.

The current behavior is correct (or rather, it's the best we can do)

You removed the parenthetical :)! It is "correct" according to the spec, and unfortunate that it's the best we can do.

Absent external configuration (such as a build definition), and a lot of additional logic, I don't think there's a way to address this problem. I'd be happy to hear otherwise.

Gopls, by design, executes only modular (package-at-a-time) analyses in real time, analogous to a compiler. By contrast, whole program analyses such as the linker or govulncheck aren't executed in real time because they need additional external information--such as which main package(s) to operate on---which means their diagnostics are not a function of a package and its transitive closure. As you can imagine, this makes them prohibitively expensive to compute in real time. You can of course request whole-program analyses explicitly, for example by invoking a "run test" code action on Test function, or invoking govulnheck from your go.mod file.