This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Fix codeAction not decoded properly when sent from some clients
ClosedPublic

Authored by malaperle on Sep 12 2017, 11:53 AM.

Details

Summary

Fix for bug https://bugs.llvm.org/show_bug.cgi?id=34559
Also log unknown fields instead of aborting the JSON parsing because it's
common that new optional fields are added either in new versions of the protocol
or extensions.

Diff Detail

Repository
rL LLVM

Event Timeline

malaperle created this revision.Sep 12 2017, 11:53 AM
malaperle planned changes to this revision.Sep 12 2017, 11:54 AM

Will have more changes, I was testing my git+svn+arc setup.

Totally makes sense to recover by ignoring unknown fields.
Could you also add a test-case?

I couldn't find "code" : null in LSP, is that some kind of extension? What does it do?

clangd/Protocol.cpp
598 ↗(On Diff #114873)

Let's add a FIXME: to log ignored fields. (We don't pass JSONOutput here, which is used for logging, so doing an actual logging peoperly requires some refactoring).

Totally makes sense to recover by ignoring unknown fields.
Could you also add a test-case?

Sorry, this wasn't meant to be reviewed yet, I was testing git+svn

Oh, sorry, I got an email from a Herald rule and confused it with a review.

malaperle added inline comments.Sep 14 2017, 10:09 AM
clangd/Protocol.cpp
598 ↗(On Diff #114873)

I'd like to fix all occurrences of this problem since I've had this problem in other places too. I think it makes sense to log ignored fields. Do you think we should pass JSONOutput everywhere? It feels odd. How about passing the llvm::raw_ostream?

malaperle added inline comments.Sep 14 2017, 11:50 AM
clangd/Protocol.cpp
598 ↗(On Diff #114873)

I guess since JSONOutput takes care of the thead-safety, we should use it.

malaperle updated this revision to Diff 115280.Sep 14 2017, 2:07 PM

[clangd] Fix codeAction not decoded properly when sent from some clients

Summary: Fix for bug https://bugs.llvm.org/show_bug.cgi?id=34559
Also log unknown fields instead of aborting the JSON parsing because it's
common that new optional fields are added either in new versions of the protocol
or extensions.

Subscribers: ilya-biryukov

Differential Revision: https://reviews.llvm.org/D37754

malaperle edited the summary of this revision. (Show Details)Sep 14 2017, 2:08 PM
malaperle set the repository for this revision to rL LLVM.
malaperle added a project: Restricted Project.
malaperle added a reviewer: ilya-biryukov.
ilya-biryukov requested changes to this revision.Sep 15 2017, 4:21 AM

Could you please clang-format the code?
Overall looks good, just a few comments, mostly regarding code style.

clangd/Protocol.cpp
27 ↗(On Diff #115280)

Maybe use llvm::StringRef instead of clang::StringRef for constistency with other parts of the file?

27 ↗(On Diff #115280)

StringRef is cheap to copy and designed to be passed by value. Just use StringRef instead of const StringRef&.

29 ↗(On Diff #115280)

KeyValue.str().c_str() can be replaced with simply KeyValue.

598 ↗(On Diff #114873)

Sure, ideally we don't want to have access to JSONOutput::writeMessage, but we do want thread-safety for logging.
Using JSONOutput seems ok for now. I am going to change some logging logic in clangd to fix some FIXMEs I have from previous refactoring, will handle this case as well.

This revision now requires changes to proceed.Sep 15 2017, 4:21 AM
malaperle updated this revision to Diff 115403.Sep 15 2017, 6:59 AM
malaperle edited edge metadata.
malaperle marked 3 inline comments as done.

Address comments.

malaperle added inline comments.Sep 15 2017, 6:59 AM
clangd/Protocol.cpp
27 ↗(On Diff #115280)

I will blame CDT's extract method refactoring for this one :) Done.

ilya-biryukov accepted this revision.Sep 18 2017, 1:27 AM

Looks good!

This revision is now accepted and ready to land.Sep 18 2017, 1:27 AM

Would you like to wait until https://reviews.llvm.org/D37972 has landed? Or is it OK to update this part with the new logger in a subsequent patch?

Would you like to wait until https://reviews.llvm.org/D37972 has landed? Or is it OK to update this part with the new logger in a subsequent patch?

No need to, just submit your change. I'll update D37972 accordingly after your change lands.

This revision was automatically updated to reflect the committed changes.