Tolerate other keys in textDocument/documentSymbol

[meqif]

Some LSP servers such as solargraph may send additional keys in the response to textDocument/documentSymbol requests, causing errors such as the following:

Keyword argument :deprecated not one of (:name :kind :location :containerName)

The corresponding code in solargraph is the following: https://github.com/castwide/solargraph/blob/db06853eff05bb597a40babc78844524bea29139/lib/solargraph/language_server/message/text_document/document_symbol.rb

Thus, the extraneous keys must be ignored.

[joaotavora]

I don't know what the standard says about this bit, but you could also convince Solargraph's devs to not break the spec (in case it is breaking the specs). That said, perhaps some macros based on destructuring-bind could be devised that respect some global parameter that indicates eglot's leniency towards these cases, and perhaps warns insteads of erroring.

In case Solargraph isn't breaking the spec, ignore this whole rant :-)

[MaskRay]

textDocument/documentSymbol can return either SymbolInformation[] or DocumentSymbol[]. Both interfaces contain deprecated?.

Don't know TypeScript much, but I feel even if they do not, it is reasonable to allow excess properties not specified in the interfaces.
https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes#strict-object-literal-assignment-checking

[meqif]

As @MaskRay mentions, deprecated is a valid, although optional, field in either response to textDocument/documentSymbol, as can be read in the spec.

In any case, ignoring unknown fields would be a pragmatic decision in a world of decidedly less than ideal implementations of the protocol, especially if the alternative is breaking altogether (as happened in this case — the imenu integration doesn't work at all with solargraph without this fix or similar).

Do feel free to close this PR in favor of a better solution. This seemed like the least invasive and most pragmatic solution to me.

[joaotavora]

@MaskRay, @meqif I'm not saying it isn't possible. Applications should be strict about what they send, and lenient about what they receive. I'm just saying we should focus on both aspects, otherwise we'll soon be breaking the usefulness of having a spec in the first place.

[joaotavora]

Should be fixed, please test it and report here.

For the record, I think the best way to address this is to make eglot--lambda and eglot--dbind macros that accept an extra argument, which is the actual object type as defined in the spec. These macros should replace uses of jsonrpc-lambda and destructuring-bind. A global switch could then easily switch between strict/lenient.

[meqif]

I confirm it's fixed now, thank you @joaotavora!

For the record, I think the best way to address this is to make eglot--lambda and eglot--dbind macros that accept an extra argument, which is the actual object type as defined in the spec. These macros should replace uses of jsonrpc-lambda and destructuring-bind.

I agree, that does sound like a better solution.