x/tools/gopls: missing workspace diagnostics after protocol change

[findleyr]

After https://go.dev/cl/649455, I don't get diagnostics in my LSP client (coc.nvim) for files other than the current open file.

Before that change, I do.

I assume that some missing field is now causing some diagnostics to be unparseable by my client.

Should block the next release.

CC @pjweinb @adonovan

[findleyr]

Of course: we're sending 0 for the file version for closed files. I guess my client interprets that as in the past.

[pjweinb]

That CL fixed a bug. But I don't understand why @latest works ok.

[findleyr]

The CL has not been released, which is why latest works.

I understand that the CL fixed a bug, but it also changed all integer fields to not use omitempty. It seems that, without an audit, we cannot assume that those changes were semantically correct.

[adonovan]

See also #71489 (comment), which is another case where zero has a different meaning from missing, and this distinction is lost during marshaling.

[Never mind, that's the same issue that's attached to the CL that caused the regression.]

[gabyhelp]

Related Issues

• x/tools/gopls: resend diagnostics for changed files #54983 (closed)
• x/tools/gopls: new buffer does not receive diagnostics when opened #42468 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[findleyr]

The CL that caused this was reverted in https://go.dev/cl/668236, so I'll close this bug.

[findleyr]

Aha, the revert was never submitted! That's why the issue persists.

CC @adonovan