I propose closing this issue. Fixing it would appear to require figuring out which fields in which LSP protocol messages gopls doesn't use (and won't use). I see no reasonable way of doing that, other than by hand. (If we knew which fields these were, then we could either just leave them out of the generated tsprotocol.go, or write special code in place of json.Unmarshal.)

We've discussed this issue and decided that it makes sense to pursue this.

One option is to compile a list of the fields that we use in the initialization options and only add those fields to the struct in the LSP API generator. If a new field gets used in a future version, we will have to manually add it to the list of used fields.

@heschi and @ianthehat also suggested the possibility of checking the error message to get the name of the unknown field, unmarshaling the message to a map[string]interface{}, deleting the problematic field, and then trying to unmarshal to a struct again, until there are no errors. If that is feasible, that seems like it may be a better approach.

The simplest way to handle this error is to keep going if the error is an *json.UnmarshalType error. Tests show that the unmarshalled struct has all its other fields filled in properly. Probably the error should be logged.

fixed by https://go-review.googlesource.com/c/tools/+/310753
(the CL for that refers to the wrong issue)