This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Treat optional field type mismatches as soft failures
ClosedPublic

Authored by kadircet on Jan 22 2021, 6:28 AM.

Details

Summary

Clangd currently throws away any protocol messages whenever an optional
field has an unexpected type. This patch changes the behaviour to treat such
fields as missing.

This enables clangd to be more tolerant against small violations to the LSP
spec.

Fixes https://github.com/clangd/vscode-clangd/issues/134

Diff Detail

Event Timeline

kadircet created this revision.Jan 22 2021, 6:28 AM
kadircet requested review of this revision.Jan 22 2021, 6:28 AM

This is basically the reverse of D89128 + D89131.

I'm not sure if I like it, but I might be biased :-)
It was put in place after I screwed up the type of a protocol message and we didn't detect it until someone reported that some setting wasn't respected in VSCode.
A log message would have made it easier to debug, and *may* have led to us catching it, unsure.

I'd probably lean toward fixing https://github.com/clangd/vscode-clangd/issues/134 where we *know* of bad clients, but not based on the possibility alone. WDYT?

clang-tools-extra/clangd/Protocol.cpp
33

I would call this tryMap for brevity

36

On the one hand, logging a message seems better than doing this silently.
On the other, if clients have this issue, these messages are likely to be frequent (at least every message) and not so helpful: unlike the current messages they don't include the context.

37

this isn't necessarily the *field* default though! e.g. if we had KeepFingerAttachedToHand = true then setting it to 1 would result in false.
I think this coincides for all the concrete callsites here. But i'm nervous we add a pattern that could bite us later.

We could do something weird like default-allocate a T and swap it if things succeed.

40

not sure if returning always-true for chaining is helpful or misleading...

kadircet updated this revision to Diff 319321.Jan 26 2021, 9:11 AM
kadircet marked 4 inline comments as done.

As discussed offline, only treat "null" fields as missing, rather than allowing
type mismatches.

sammccall accepted this revision.Jan 27 2021, 12:40 AM
sammccall added inline comments.
clang-tools-extra/clangd/Protocol.cpp
33

Sorry... now that it can fail, I don't think tryMap is a great name anymore.

mapOptOrNull? mapNullable?

up to you

838

why are we no longer checking the value?

This revision is now accepted and ready to land.Jan 27 2021, 12:40 AM
kadircet updated this revision to Diff 319551.Jan 27 2021, 6:18 AM
kadircet marked 2 inline comments as done.
  • rename to mapOptOrNull
  • revert leftover changes.
clang-tools-extra/clangd/Protocol.cpp
33

going with mapOptOrNull.

838

oops, i was trying something different at some point and looks like i forgot to revert some of those changes ..

This revision was landed with ongoing or failed builds.Jan 27 2021, 6:52 AM
This revision was automatically updated to reflect the committed changes.