This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Enable snippet completion based on client capabilities.
ClosedPublic

Authored by ilya-biryukov on Feb 13 2018, 3:24 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

ilya-biryukov created this revision.Feb 13 2018, 3:24 AM
ioeric accepted this revision.Feb 15 2018, 2:13 AM

lgtm

clangd/ClangdLSPServer.cpp
90 ↗(On Diff #134016)

This was moved from the end to the top. Is this related to the snippet change here?

clangd/Protocol.h
184 ↗(On Diff #134016)

Use default Optional? I think we would treat empty optional the same as false anyway?

clangd/tool/ClangdMain.cpp
60 ↗(On Diff #134016)

Would we still have a way to disable snippets (e.g. for debugging) even if clients support them? Maybe make this a hidden option instead?

This revision is now accepted and ready to land.Feb 15 2018, 2:13 AM
ilya-biryukov marked an inline comment as done.
  • Remove initializers from Optional<> fields
clangd/ClangdLSPServer.cpp
90 ↗(On Diff #134016)

Not really, I just thought it's nicer to reply after we process the request (e.g., if we crash for any reason it will happen before client receives the reply).
Can move it back down. WDYT?

clangd/Protocol.h
184 ↗(On Diff #134016)

Thanks for spotting that, I forgot to update this.

clangd/tool/ClangdMain.cpp
60 ↗(On Diff #134016)

I'm tempted to say in that case we could just recompile clangd so that it ignores the options (i.e. change onInitialized). The code that will take it into account would be a bit trickier (you can't just pass CodeCompleteOptions to ClangdLSPServer, we'll also have to pass Optional<bool> OverridenEnableSnippets).

sammccall added inline comments.Feb 15 2018, 5:07 AM
clangd/tool/ClangdMain.cpp
60 ↗(On Diff #134016)

+1 to this - this is really a debugging option, and supporting it has a cost.

If we want debugging options to live forever (may be reasonable!) we need a more scalable way to define them than listing them all in ClangdMain.

test/clangd/completion-snippets-disabled.test
1 ↗(On Diff #134405)

Please don't add three new lit tests for this. One should be certainly enough (off, assuming our normal completion test has this feature on).

But really I think this can be a unit test in CodeComplete tests instead, right?

If you really want to verify how missing snippetSupport parses, that's a unittest for protocol.h right? But it doesn't seem important.

ilya-biryukov added inline comments.Feb 15 2018, 5:29 AM
test/clangd/completion-snippets-disabled.test
1 ↗(On Diff #134405)

Please don't add three new lit tests for this. One should be certainly enough (off, assuming our normal completion test has this feature on).

Our completion lit test include empty capabilities, we don't test it there at all.

But really I think this can be a unit test in CodeComplete tests instead, right?

We already have a test for that in CodeComplete, but I think we should have a small integration test that cover all three cases where snippetSupport is on, off and missing.
We could sneak in the "missing" case into the existing completion.test, but on/off tests are useful to have from my perspective.

If you really want to verify how missing snippetSupport parses, that's a unittest for protocol.h right? But it doesn't seem important.

I'm not sure checking the parsing code makes sense (it's close to being "correct by construction" from my point of view). Checking that LSP outputs the right thing seems useful, though.

  • Use default values for configuration instead of using Optional<> fields.
  • Removed redundant tests.
  • Removed completion-snippets-missing.test

As discussed offline with @sammccall, we don't really need to hold Optional<> fields for configuration entries, as we only consume them in clangd and therefore can just set the default values explicitly.
Makes the code simpler and requires only one extra test (with snippets enabled).

This revision was automatically updated to reflect the committed changes.