@sqs I've tagged you in this PR because you wrote that code and it's very unclear from the docs why it's doing that. Please let me know what you think?

Thanks for digging into this.

A response of {"id":123,"result":{},"jsonrpc":"2.0"} is a correct "no result found" response for some LSP methods, such as textDocument/definition. It was coincidental (well, somewhat of a convenience that no longer works) that return nil, nil mapped to that JSON-RPC response. I had return nil, nil to indicate "there is no definition found but there is also no unexpected error", as "no definition found" is not really considered an error at the LSP level. This was a fragile hack.

I think that if handleDefinition encounters "there is no definition found but there is also no unexpected error", it should return a sentinel error value like ErrNoDefinition that is translated into {"id":123,"result":{},"jsonrpc":"2.0"}, not a JSON-RPC error ({"id":123,"error":{...whatever...},"jsonrpc":"2.0"}), by the response handler. That means the handler should basically do if err == ErrNoDefinition { return struct{}{}, nil } in textDocument/definition.

This makes it unclear to me whether or not the conversion into a struct is truly correct or not.

It is not. That is code I wrote and I see it is incorrect. An JSON-RPC 2.0 response's result can be any JSON type (http://www.jsonrpc.org/specification#response_object, note result has no constraints on type, unlike params in section 4.2). The jsonrpc2.HandlerWithError should return {..., "result":null} if the result interface{} return value is nil, and an LSP handler should never return nil, nil (because afaik null does not appear in any methods' specification as a valid value for the result field).

I think that if handleDefinition encounters

Nevermind about this paragraph. I see that your change accomplishes the same result with less code (I had forgotten handleDefinition directly returns the LSP result).

textDocument/xdefintition must return an empty array if no result was found. Neither null or an empty object {} are valid return types. If there was an error, result must be omitted from the JSON, null is not valid either.

@felixfbecker FYI in go by default an empty slice (ie empty list) is nil.

var foo []string // foo is nil at this point
foo = append(foo, "hello world") // now foo is not nil

// instead you can do this, but this isn't idiomatic
foo := []string{}