2017-02-07 18:28:20 +08:00
|
|
|
//===--- Protocol.cpp - Language Server Protocol Implementation -----------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file contains the serialization code for the LSP structs.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "Protocol.h"
|
2018-01-29 23:37:46 +08:00
|
|
|
#include "Logger.h"
|
2018-02-16 20:20:47 +08:00
|
|
|
#include "URI.h"
|
2017-02-07 18:28:20 +08:00
|
|
|
#include "clang/Basic/LLVM.h"
|
|
|
|
#include "llvm/ADT/SmallString.h"
|
|
|
|
#include "llvm/Support/Format.h"
|
2017-09-18 23:02:59 +08:00
|
|
|
#include "llvm/Support/FormatVariadic.h"
|
2017-04-07 19:03:26 +08:00
|
|
|
#include "llvm/Support/Path.h"
|
2017-08-02 17:08:39 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2017-09-20 15:24:15 +08:00
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
namespace clang {
|
|
|
|
namespace clangd {
|
2018-07-09 22:25:59 +08:00
|
|
|
using namespace llvm;
|
2017-11-29 19:36:46 +08:00
|
|
|
|
2018-02-16 20:20:47 +08:00
|
|
|
URIForFile::URIForFile(std::string AbsPath) {
|
|
|
|
assert(llvm::sys::path::is_absolute(AbsPath) && "the path is relative");
|
|
|
|
File = std::move(AbsPath);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &E, URIForFile &R) {
|
|
|
|
if (auto S = E.getAsString()) {
|
2018-01-29 23:37:46 +08:00
|
|
|
auto U = URI::parse(*S);
|
|
|
|
if (!U) {
|
[clangd] Upgrade logging facilities with levels and formatv.
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
2018-07-11 18:35:11 +08:00
|
|
|
elog("Failed to parse URI {0}: {1}", *S, U.takeError());
|
2018-01-29 23:37:46 +08:00
|
|
|
return false;
|
|
|
|
}
|
2018-02-01 00:26:27 +08:00
|
|
|
if (U->scheme() != "file" && U->scheme() != "test") {
|
[clangd] Upgrade logging facilities with levels and formatv.
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
2018-07-11 18:35:11 +08:00
|
|
|
elog("Clangd only supports 'file' URI scheme for workspace files: {0}",
|
|
|
|
*S);
|
2018-01-29 23:37:46 +08:00
|
|
|
return false;
|
|
|
|
}
|
2018-01-30 19:23:11 +08:00
|
|
|
auto Path = URI::resolve(*U);
|
|
|
|
if (!Path) {
|
[clangd] Upgrade logging facilities with levels and formatv.
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
2018-07-11 18:35:11 +08:00
|
|
|
log("{0}", Path.takeError());
|
2018-01-30 19:23:11 +08:00
|
|
|
return false;
|
|
|
|
}
|
2018-02-16 20:20:47 +08:00
|
|
|
R = URIForFile(*Path);
|
2017-12-01 05:32:29 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
2017-11-29 19:36:46 +08:00
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const URIForFile &U) { return U.uri(); }
|
2017-04-07 19:03:26 +08:00
|
|
|
|
2018-01-29 23:37:46 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const URIForFile &U) {
|
|
|
|
return OS << U.uri();
|
2017-12-20 18:26:53 +08:00
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const TextDocumentIdentifier &R) {
|
|
|
|
return json::Object{{"uri", R.uri}};
|
2018-02-16 22:15:55 +08:00
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, TextDocumentIdentifier &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("uri", R.uri);
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, Position &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("line", R.line) && O.map("character", R.character);
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const Position &P) {
|
|
|
|
return json::Object{
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
{"line", P.line},
|
|
|
|
{"character", P.character},
|
|
|
|
};
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2017-12-20 18:26:53 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const Position &P) {
|
|
|
|
return OS << P.line << ':' << P.character;
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, Range &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("start", R.start) && O.map("end", R.end);
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const Range &P) {
|
|
|
|
return json::Object{
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
{"start", P.start},
|
|
|
|
{"end", P.end},
|
|
|
|
};
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2017-12-20 18:26:53 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const Range &R) {
|
|
|
|
return OS << R.start << '-' << R.end;
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const Location &P) {
|
|
|
|
return json::Object{
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
{"uri", P.uri},
|
|
|
|
{"range", P.range},
|
|
|
|
};
|
2017-06-29 00:12:10 +08:00
|
|
|
}
|
|
|
|
|
2017-12-20 18:26:53 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const Location &L) {
|
|
|
|
return OS << L.range << '@' << L.uri;
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, TextDocumentItem &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("uri", R.uri) && O.map("languageId", R.languageId) &&
|
|
|
|
O.map("version", R.version) && O.map("text", R.text);
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, Metadata &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
2017-11-28 17:37:43 +08:00
|
|
|
if (!O)
|
2017-12-01 05:32:29 +08:00
|
|
|
return false;
|
|
|
|
O.map("extraFlags", R.extraFlags);
|
|
|
|
return true;
|
2017-07-06 16:44:54 +08:00
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, TextEdit &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("range", R.range) && O.map("newText", R.newText);
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const TextEdit &P) {
|
|
|
|
return json::Object{
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
{"range", P.range},
|
|
|
|
{"newText", P.newText},
|
|
|
|
};
|
[clangd] Handle clangd.applyFix server-side
Summary:
When the user selects a fix-it (or any code action with commands), it is
possible to let the client forward the selected command to the server.
When the clangd.applyFix command is handled on the server, it can send a
workspace/applyEdit request to the client. This has the advantage that
the client doesn't explicitly have to know how to handle
clangd.applyFix. Therefore, the code to handle clangd.applyFix in the VS
Code extension (and any other Clangd client) is not required anymore.
Reviewers: ilya-biryukov, sammccall, Nebiroth, hokein
Reviewed By: hokein
Subscribers: ioeric, hokein, rwols, puremourning, bkramer, ilya-biryukov
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D39276
llvm-svn: 317322
2017-11-03 21:39:15 +08:00
|
|
|
}
|
|
|
|
|
2018-01-26 01:29:17 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const TextEdit &TE) {
|
|
|
|
OS << TE.range << " => \"";
|
2018-06-01 01:36:31 +08:00
|
|
|
printEscapedString(TE.newText, OS);
|
2018-01-26 01:29:17 +08:00
|
|
|
return OS << '"';
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &E, TraceLevel &Out) {
|
|
|
|
if (auto S = E.getAsString()) {
|
2017-12-01 05:32:29 +08:00
|
|
|
if (*S == "off") {
|
|
|
|
Out = TraceLevel::Off;
|
|
|
|
return true;
|
|
|
|
} else if (*S == "messages") {
|
|
|
|
Out = TraceLevel::Messages;
|
|
|
|
return true;
|
|
|
|
} else if (*S == "verbose") {
|
|
|
|
Out = TraceLevel::Verbose;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, CompletionItemClientCapabilities &R) {
|
2018-02-15 22:32:57 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
if (!O)
|
|
|
|
return false;
|
|
|
|
O.map("snippetSupport", R.snippetSupport);
|
|
|
|
O.map("commitCharacterSupport", R.commitCharacterSupport);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, CompletionClientCapabilities &R) {
|
2018-02-15 22:32:57 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
if (!O)
|
|
|
|
return false;
|
|
|
|
O.map("dynamicRegistration", R.dynamicRegistration);
|
|
|
|
O.map("completionItem", R.completionItem);
|
|
|
|
O.map("contextSupport", R.contextSupport);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2018-08-11 01:25:07 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params,
|
|
|
|
PublishDiagnosticsClientCapabilities &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
if (!O)
|
|
|
|
return false;
|
|
|
|
O.map("clangdFixSupport", R.clangdFixSupport);
|
2018-08-23 04:30:06 +08:00
|
|
|
O.map("categorySupport", R.categorySupport);
|
2018-08-11 01:25:07 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &E, SymbolKind &Out) {
|
|
|
|
if (auto T = E.getAsInteger()) {
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
if (*T < static_cast<int>(SymbolKind::File) ||
|
|
|
|
*T > static_cast<int>(SymbolKind::TypeParameter))
|
|
|
|
return false;
|
|
|
|
Out = static_cast<SymbolKind>(*T);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &E, std::vector<SymbolKind> &Out) {
|
|
|
|
if (auto *A = E.getAsArray()) {
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
Out.clear();
|
|
|
|
for (size_t I = 0; I < A->size(); ++I) {
|
|
|
|
SymbolKind KindOut;
|
|
|
|
if (fromJSON((*A)[I], KindOut))
|
|
|
|
Out.push_back(KindOut);
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, SymbolKindCapabilities &R) {
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("valueSet", R.valueSet);
|
|
|
|
}
|
|
|
|
|
|
|
|
SymbolKind adjustKindToCapability(SymbolKind Kind,
|
2018-07-26 20:05:31 +08:00
|
|
|
SymbolKindBitset &SupportedSymbolKinds) {
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
auto KindVal = static_cast<size_t>(Kind);
|
2018-07-26 20:05:31 +08:00
|
|
|
if (KindVal >= SymbolKindMin && KindVal <= SupportedSymbolKinds.size() &&
|
|
|
|
SupportedSymbolKinds[KindVal])
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
return Kind;
|
|
|
|
|
|
|
|
switch (Kind) {
|
|
|
|
// Provide some fall backs for common kinds that are close enough.
|
|
|
|
case SymbolKind::Struct:
|
|
|
|
return SymbolKind::Class;
|
|
|
|
case SymbolKind::EnumMember:
|
|
|
|
return SymbolKind::Enum;
|
|
|
|
default:
|
|
|
|
return SymbolKind::String;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, WorkspaceSymbolCapabilities &R) {
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("symbolKind", R.symbolKind);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, WorkspaceClientCapabilities &R) {
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("symbol", R.symbol);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, TextDocumentClientCapabilities &R) {
|
2018-02-15 22:32:57 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
if (!O)
|
|
|
|
return false;
|
|
|
|
O.map("completion", R.completion);
|
2018-08-11 01:25:07 +08:00
|
|
|
O.map("publishDiagnostics", R.publishDiagnostics);
|
2018-02-15 22:32:57 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, ClientCapabilities &R) {
|
2018-02-15 22:32:57 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
if (!O)
|
|
|
|
return false;
|
|
|
|
O.map("textDocument", R.textDocument);
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
O.map("workspace", R.workspace);
|
2018-02-15 22:32:57 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, InitializeParams &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
2017-11-28 17:37:43 +08:00
|
|
|
if (!O)
|
2017-12-01 05:32:29 +08:00
|
|
|
return false;
|
2017-11-29 19:36:46 +08:00
|
|
|
// We deliberately don't fail if we can't parse individual fields.
|
|
|
|
// Failing to handle a slightly malformed initialize would be a disaster.
|
2017-12-01 05:32:29 +08:00
|
|
|
O.map("processId", R.processId);
|
|
|
|
O.map("rootUri", R.rootUri);
|
|
|
|
O.map("rootPath", R.rootPath);
|
2018-02-15 22:32:57 +08:00
|
|
|
O.map("capabilities", R.capabilities);
|
2017-12-01 05:32:29 +08:00
|
|
|
O.map("trace", R.trace);
|
2018-08-01 19:28:49 +08:00
|
|
|
O.map("initializationOptions", R.initializationOptions);
|
2017-12-01 05:32:29 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, DidOpenTextDocumentParams &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("metadata", R.metadata);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, DidCloseTextDocumentParams &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, DidChangeTextDocumentParams &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
2018-02-23 02:40:39 +08:00
|
|
|
O.map("contentChanges", R.contentChanges) &&
|
|
|
|
O.map("wantDiagnostics", R.wantDiagnostics);
|
2017-12-01 05:32:29 +08:00
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &E, FileChangeType &Out) {
|
|
|
|
if (auto T = E.getAsInteger()) {
|
2017-12-01 05:32:29 +08:00
|
|
|
if (*T < static_cast<int>(FileChangeType::Created) ||
|
|
|
|
*T > static_cast<int>(FileChangeType::Deleted))
|
|
|
|
return false;
|
|
|
|
Out = static_cast<FileChangeType>(*T);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, FileEvent &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("uri", R.uri) && O.map("type", R.type);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, DidChangeWatchedFilesParams &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("changes", R.changes);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, TextDocumentContentChangeEvent &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
[clangd] Support incremental document syncing
Summary:
This patch adds support for incremental document syncing, as described
in the LSP spec. The protocol specifies ranges in terms of Position (a
line and a character), and our drafts are stored as plain strings. So I
see two things that may not be super efficient for very large files:
- Converting a Position to an offset (the positionToOffset function)
requires searching for end of lines until we reach the desired line.
- When we update a range, we construct a new string, which implies
copying the whole document.
However, for the typical size of a C++ document and the frequency of
update (at which a user types), it may not be an issue. This patch aims
at getting the basic feature in, and we can always improve it later if
we find it's too slow.
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Reviewers: malaperle, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: MaskRay, klimek, mgorny, ilya-biryukov, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D44272
llvm-svn: 328500
2018-03-26 22:41:40 +08:00
|
|
|
return O && O.map("range", R.range) && O.map("rangeLength", R.rangeLength) &&
|
|
|
|
O.map("text", R.text);
|
2017-12-01 05:32:29 +08:00
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, FormattingOptions &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("tabSize", R.tabSize) &&
|
|
|
|
O.map("insertSpaces", R.insertSpaces);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const FormattingOptions &P) {
|
|
|
|
return json::Object{
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
{"tabSize", P.tabSize},
|
|
|
|
{"insertSpaces", P.insertSpaces},
|
|
|
|
};
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, DocumentRangeFormattingParams &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("range", R.range) && O.map("options", R.options);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, DocumentOnTypeFormattingParams &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("position", R.position) && O.map("ch", R.ch) &&
|
|
|
|
O.map("options", R.options);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, DocumentFormattingParams &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("options", R.options);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, DocumentSymbolParams &R) {
|
2018-07-06 03:35:01 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, Diagnostic &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
if (!O || !O.map("range", R.range) || !O.map("message", R.message))
|
|
|
|
return false;
|
|
|
|
O.map("severity", R.severity);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, CodeActionContext &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("diagnostics", R.diagnostics);
|
|
|
|
}
|
|
|
|
|
2018-01-26 01:29:17 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const Diagnostic &D) {
|
|
|
|
OS << D.range << " [";
|
|
|
|
switch (D.severity) {
|
|
|
|
case 1:
|
|
|
|
OS << "error";
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
OS << "warning";
|
|
|
|
break;
|
|
|
|
case 3:
|
|
|
|
OS << "note";
|
|
|
|
break;
|
|
|
|
case 4:
|
|
|
|
OS << "remark";
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
OS << "diagnostic";
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return OS << '(' << D.severity << "): " << D.message << "]";
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, CodeActionParams &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("range", R.range) && O.map("context", R.context);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, WorkspaceEdit &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("changes", R.changes);
|
[clangd] Handle clangd.applyFix server-side
Summary:
When the user selects a fix-it (or any code action with commands), it is
possible to let the client forward the selected command to the server.
When the clangd.applyFix command is handled on the server, it can send a
workspace/applyEdit request to the client. This has the advantage that
the client doesn't explicitly have to know how to handle
clangd.applyFix. Therefore, the code to handle clangd.applyFix in the VS
Code extension (and any other Clangd client) is not required anymore.
Reviewers: ilya-biryukov, sammccall, Nebiroth, hokein
Reviewed By: hokein
Subscribers: ioeric, hokein, rwols, puremourning, bkramer, ilya-biryukov
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D39276
llvm-svn: 317322
2017-11-03 21:39:15 +08:00
|
|
|
}
|
|
|
|
|
2017-12-28 23:03:02 +08:00
|
|
|
const llvm::StringLiteral ExecuteCommandParams::CLANGD_APPLY_FIX_COMMAND =
|
[clangd] Handle clangd.applyFix server-side
Summary:
When the user selects a fix-it (or any code action with commands), it is
possible to let the client forward the selected command to the server.
When the clangd.applyFix command is handled on the server, it can send a
workspace/applyEdit request to the client. This has the advantage that
the client doesn't explicitly have to know how to handle
clangd.applyFix. Therefore, the code to handle clangd.applyFix in the VS
Code extension (and any other Clangd client) is not required anymore.
Reviewers: ilya-biryukov, sammccall, Nebiroth, hokein
Reviewed By: hokein
Subscribers: ioeric, hokein, rwols, puremourning, bkramer, ilya-biryukov
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D39276
llvm-svn: 317322
2017-11-03 21:39:15 +08:00
|
|
|
"clangd.applyFix";
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, ExecuteCommandParams &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
if (!O || !O.map("command", R.command))
|
|
|
|
return false;
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
auto Args = Params.getAsObject()->getArray("arguments");
|
2017-12-01 05:32:29 +08:00
|
|
|
if (R.command == ExecuteCommandParams::CLANGD_APPLY_FIX_COMMAND) {
|
|
|
|
return Args && Args->size() == 1 &&
|
|
|
|
fromJSON(Args->front(), R.workspaceEdit);
|
|
|
|
}
|
|
|
|
return false; // Unrecognized command.
|
[clangd] Handle clangd.applyFix server-side
Summary:
When the user selects a fix-it (or any code action with commands), it is
possible to let the client forward the selected command to the server.
When the clangd.applyFix command is handled on the server, it can send a
workspace/applyEdit request to the client. This has the advantage that
the client doesn't explicitly have to know how to handle
clangd.applyFix. Therefore, the code to handle clangd.applyFix in the VS
Code extension (and any other Clangd client) is not required anymore.
Reviewers: ilya-biryukov, sammccall, Nebiroth, hokein
Reviewed By: hokein
Subscribers: ioeric, hokein, rwols, puremourning, bkramer, ilya-biryukov
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D39276
llvm-svn: 317322
2017-11-03 21:39:15 +08:00
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const SymbolInformation &P) {
|
|
|
|
return json::Object{
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
{"name", P.name},
|
|
|
|
{"kind", static_cast<int>(P.kind)},
|
|
|
|
{"location", P.location},
|
|
|
|
{"containerName", P.containerName},
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &O,
|
|
|
|
const SymbolInformation &SI) {
|
|
|
|
O << SI.containerName << "::" << SI.name << " - " << toJSON(SI);
|
|
|
|
return O;
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, WorkspaceSymbolParams &R) {
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("query", R.query);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const Command &C) {
|
|
|
|
auto Cmd = json::Object{{"title", C.title}, {"command", C.command}};
|
2018-02-16 22:15:55 +08:00
|
|
|
if (C.workspaceEdit)
|
|
|
|
Cmd["arguments"] = {*C.workspaceEdit};
|
|
|
|
return std::move(Cmd);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const WorkspaceEdit &WE) {
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
if (!WE.changes)
|
2018-07-09 22:25:59 +08:00
|
|
|
return json::Object{};
|
|
|
|
json::Object FileChanges;
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
for (auto &Change : *WE.changes)
|
2018-07-09 22:25:59 +08:00
|
|
|
FileChanges[Change.first] = json::Array(Change.second);
|
|
|
|
return json::Object{{"changes", std::move(FileChanges)}};
|
[clangd] Handle clangd.applyFix server-side
Summary:
When the user selects a fix-it (or any code action with commands), it is
possible to let the client forward the selected command to the server.
When the clangd.applyFix command is handled on the server, it can send a
workspace/applyEdit request to the client. This has the advantage that
the client doesn't explicitly have to know how to handle
clangd.applyFix. Therefore, the code to handle clangd.applyFix in the VS
Code extension (and any other Clangd client) is not required anymore.
Reviewers: ilya-biryukov, sammccall, Nebiroth, hokein
Reviewed By: hokein
Subscribers: ioeric, hokein, rwols, puremourning, bkramer, ilya-biryukov
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D39276
llvm-svn: 317322
2017-11-03 21:39:15 +08:00
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const ApplyWorkspaceEditParams &Params) {
|
|
|
|
return json::Object{{"edit", Params.edit}};
|
[clangd] Handle clangd.applyFix server-side
Summary:
When the user selects a fix-it (or any code action with commands), it is
possible to let the client forward the selected command to the server.
When the clangd.applyFix command is handled on the server, it can send a
workspace/applyEdit request to the client. This has the advantage that
the client doesn't explicitly have to know how to handle
clangd.applyFix. Therefore, the code to handle clangd.applyFix in the VS
Code extension (and any other Clangd client) is not required anymore.
Reviewers: ilya-biryukov, sammccall, Nebiroth, hokein
Reviewed By: hokein
Subscribers: ioeric, hokein, rwols, puremourning, bkramer, ilya-biryukov
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D39276
llvm-svn: 317322
2017-11-03 21:39:15 +08:00
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, TextDocumentPositionParams &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("position", R.position);
|
2017-04-04 17:46:39 +08:00
|
|
|
}
|
|
|
|
|
[clangd] Implement textDocument/hover
Summary: Implemention of textDocument/hover as described in LSP definition.
This patch adds a basic Hover implementation. When hovering a variable,
function, method or namespace, clangd will return a text containing the
declaration's scope, as well as the declaration of the hovered entity.
For example, for a variable:
Declared in class Foo::Bar
int hello = 2
For macros, the macro definition is returned.
This patch doesn't include:
- markdown support (the client I use doesn't support it yet)
- range support (optional in the Hover response)
- comments associated to variables/functions/classes
They are kept as future work to keep this patch simpler.
I added tests in XRefsTests.cpp. hover.test contains one simple
smoketest to make sure the feature works from a black box perspective.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: sammccall, mgrang, klimek, rwols, ilya-biryukov, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D35894
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325395
2018-02-17 05:38:15 +08:00
|
|
|
static StringRef toTextKind(MarkupKind Kind) {
|
|
|
|
switch (Kind) {
|
|
|
|
case MarkupKind::PlainText:
|
|
|
|
return "plaintext";
|
|
|
|
case MarkupKind::Markdown:
|
|
|
|
return "markdown";
|
|
|
|
}
|
|
|
|
llvm_unreachable("Invalid MarkupKind");
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const MarkupContent &MC) {
|
2018-02-17 07:12:26 +08:00
|
|
|
if (MC.value.empty())
|
[clangd] Implement textDocument/hover
Summary: Implemention of textDocument/hover as described in LSP definition.
This patch adds a basic Hover implementation. When hovering a variable,
function, method or namespace, clangd will return a text containing the
declaration's scope, as well as the declaration of the hovered entity.
For example, for a variable:
Declared in class Foo::Bar
int hello = 2
For macros, the macro definition is returned.
This patch doesn't include:
- markdown support (the client I use doesn't support it yet)
- range support (optional in the Hover response)
- comments associated to variables/functions/classes
They are kept as future work to keep this patch simpler.
I added tests in XRefsTests.cpp. hover.test contains one simple
smoketest to make sure the feature works from a black box perspective.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: sammccall, mgrang, klimek, rwols, ilya-biryukov, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D35894
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325395
2018-02-17 05:38:15 +08:00
|
|
|
return nullptr;
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
return json::Object{
|
2018-02-17 07:12:26 +08:00
|
|
|
{"kind", toTextKind(MC.kind)},
|
|
|
|
{"value", MC.value},
|
[clangd] Implement textDocument/hover
Summary: Implemention of textDocument/hover as described in LSP definition.
This patch adds a basic Hover implementation. When hovering a variable,
function, method or namespace, clangd will return a text containing the
declaration's scope, as well as the declaration of the hovered entity.
For example, for a variable:
Declared in class Foo::Bar
int hello = 2
For macros, the macro definition is returned.
This patch doesn't include:
- markdown support (the client I use doesn't support it yet)
- range support (optional in the Hover response)
- comments associated to variables/functions/classes
They are kept as future work to keep this patch simpler.
I added tests in XRefsTests.cpp. hover.test contains one simple
smoketest to make sure the feature works from a black box perspective.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: sammccall, mgrang, klimek, rwols, ilya-biryukov, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D35894
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325395
2018-02-17 05:38:15 +08:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const Hover &H) {
|
|
|
|
json::Object Result{{"contents", toJSON(H.contents)}};
|
[clangd] Implement textDocument/hover
Summary: Implemention of textDocument/hover as described in LSP definition.
This patch adds a basic Hover implementation. When hovering a variable,
function, method or namespace, clangd will return a text containing the
declaration's scope, as well as the declaration of the hovered entity.
For example, for a variable:
Declared in class Foo::Bar
int hello = 2
For macros, the macro definition is returned.
This patch doesn't include:
- markdown support (the client I use doesn't support it yet)
- range support (optional in the Hover response)
- comments associated to variables/functions/classes
They are kept as future work to keep this patch simpler.
I added tests in XRefsTests.cpp. hover.test contains one simple
smoketest to make sure the feature works from a black box perspective.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: sammccall, mgrang, klimek, rwols, ilya-biryukov, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D35894
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325395
2018-02-17 05:38:15 +08:00
|
|
|
|
2018-02-17 07:12:26 +08:00
|
|
|
if (H.range.hasValue())
|
|
|
|
Result["range"] = toJSON(*H.range);
|
[clangd] Implement textDocument/hover
Summary: Implemention of textDocument/hover as described in LSP definition.
This patch adds a basic Hover implementation. When hovering a variable,
function, method or namespace, clangd will return a text containing the
declaration's scope, as well as the declaration of the hovered entity.
For example, for a variable:
Declared in class Foo::Bar
int hello = 2
For macros, the macro definition is returned.
This patch doesn't include:
- markdown support (the client I use doesn't support it yet)
- range support (optional in the Hover response)
- comments associated to variables/functions/classes
They are kept as future work to keep this patch simpler.
I added tests in XRefsTests.cpp. hover.test contains one simple
smoketest to make sure the feature works from a black box perspective.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: sammccall, mgrang, klimek, rwols, ilya-biryukov, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D35894
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325395
2018-02-17 05:38:15 +08:00
|
|
|
|
|
|
|
return std::move(Result);
|
|
|
|
}
|
|
|
|
|
2018-09-28 01:13:07 +08:00
|
|
|
bool fromJSON(const json::Value &E, CompletionItemKind &Out) {
|
|
|
|
if (auto T = E.getAsInteger()) {
|
|
|
|
if (*T < static_cast<int>(CompletionItemKind::Text) ||
|
|
|
|
*T > static_cast<int>(CompletionItemKind::TypeParameter))
|
|
|
|
return false;
|
|
|
|
Out = static_cast<CompletionItemKind>(*T);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
CompletionItemKind
|
|
|
|
adjustKindToCapability(CompletionItemKind Kind,
|
|
|
|
CompletionItemKindBitset &supportedCompletionItemKinds) {
|
|
|
|
auto KindVal = static_cast<size_t>(Kind);
|
|
|
|
if (KindVal >= CompletionItemKindMin &&
|
|
|
|
KindVal <= supportedCompletionItemKinds.size() &&
|
|
|
|
supportedCompletionItemKinds[KindVal])
|
|
|
|
return Kind;
|
|
|
|
|
|
|
|
switch (Kind) {
|
|
|
|
// Provide some fall backs for common kinds that are close enough.
|
|
|
|
case CompletionItemKind::Folder:
|
|
|
|
return CompletionItemKind::File;
|
|
|
|
case CompletionItemKind::EnumMember:
|
|
|
|
return CompletionItemKind::Enum;
|
|
|
|
case CompletionItemKind::Struct:
|
|
|
|
return CompletionItemKind::Class;
|
|
|
|
default:
|
|
|
|
return CompletionItemKind::Text;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const json::Value &E, std::vector<CompletionItemKind> &Out) {
|
|
|
|
if (auto *A = E.getAsArray()) {
|
|
|
|
Out.clear();
|
|
|
|
for (size_t I = 0; I < A->size(); ++I) {
|
|
|
|
CompletionItemKind KindOut;
|
|
|
|
if (fromJSON((*A)[I], KindOut))
|
|
|
|
Out.push_back(KindOut);
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const json::Value &Params, CompletionItemKindCapabilities &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("valueSet", R.valueSet);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const CompletionItem &CI) {
|
2017-04-04 17:46:39 +08:00
|
|
|
assert(!CI.label.empty() && "completion item label is required");
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Object Result{{"label", CI.label}};
|
2017-04-04 17:46:39 +08:00
|
|
|
if (CI.kind != CompletionItemKind::Missing)
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
Result["kind"] = static_cast<int>(CI.kind);
|
2017-04-04 17:46:39 +08:00
|
|
|
if (!CI.detail.empty())
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
Result["detail"] = CI.detail;
|
2017-04-04 17:46:39 +08:00
|
|
|
if (!CI.documentation.empty())
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
Result["documentation"] = CI.documentation;
|
2017-04-04 17:46:39 +08:00
|
|
|
if (!CI.sortText.empty())
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
Result["sortText"] = CI.sortText;
|
2017-04-04 17:46:39 +08:00
|
|
|
if (!CI.filterText.empty())
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
Result["filterText"] = CI.filterText;
|
2017-04-04 17:46:39 +08:00
|
|
|
if (!CI.insertText.empty())
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
Result["insertText"] = CI.insertText;
|
|
|
|
if (CI.insertTextFormat != InsertTextFormat::Missing)
|
|
|
|
Result["insertTextFormat"] = static_cast<int>(CI.insertTextFormat);
|
2017-04-04 17:46:39 +08:00
|
|
|
if (CI.textEdit)
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
Result["textEdit"] = *CI.textEdit;
|
|
|
|
if (!CI.additionalTextEdits.empty())
|
2018-07-09 22:25:59 +08:00
|
|
|
Result["additionalTextEdits"] = json::Array(CI.additionalTextEdits);
|
2018-09-07 02:52:26 +08:00
|
|
|
if (CI.deprecated)
|
|
|
|
Result["deprecated"] = CI.deprecated;
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
return std::move(Result);
|
2017-04-04 17:46:39 +08:00
|
|
|
}
|
2017-10-06 19:54:17 +08:00
|
|
|
|
[clangd] Use operator<< to prevent printers issues in Gtest
Summary:
It is possible that there will be two different instantiations of
the printer template for a given type and some tests could end up calling the
wrong (default) one. For example, it was seen in CodeCompleteTests.cpp when
printing CompletionItems that it would use the wrong printer because the default
is also instantiated in ClangdTests.cpp.
With this change, objects that were previously printed with a custom Printer now
get printed through the operator<< which is declared alongside the class.
This rule of the thumb should make it less error-prone.
Reviewers: simark, ilya-biryukov, sammccall
Reviewed By: simark, ilya-biryukov, sammccall
Subscribers: bkramer, hokein, sammccall, klimek, ilya-biryukov, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44764
llvm-svn: 329725
2018-04-11 01:34:46 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &O, const CompletionItem &I) {
|
|
|
|
O << I.label << " - " << toJSON(I);
|
|
|
|
return O;
|
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
bool operator<(const CompletionItem &L, const CompletionItem &R) {
|
2017-11-08 15:44:12 +08:00
|
|
|
return (L.sortText.empty() ? L.label : L.sortText) <
|
|
|
|
(R.sortText.empty() ? R.label : R.sortText);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const CompletionList &L) {
|
|
|
|
return json::Object{
|
2017-11-15 17:16:29 +08:00
|
|
|
{"isIncomplete", L.isIncomplete},
|
2018-07-09 22:25:59 +08:00
|
|
|
{"items", json::Array(L.items)},
|
2017-11-15 17:16:29 +08:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const ParameterInformation &PI) {
|
2017-10-06 19:54:17 +08:00
|
|
|
assert(!PI.label.empty() && "parameter information label is required");
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Object Result{{"label", PI.label}};
|
2017-10-06 19:54:17 +08:00
|
|
|
if (!PI.documentation.empty())
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
Result["documentation"] = PI.documentation;
|
|
|
|
return std::move(Result);
|
2017-10-06 19:54:17 +08:00
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const SignatureInformation &SI) {
|
2017-10-06 19:54:17 +08:00
|
|
|
assert(!SI.label.empty() && "signature information label is required");
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Object Result{
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
{"label", SI.label},
|
2018-07-09 22:25:59 +08:00
|
|
|
{"parameters", json::Array(SI.parameters)},
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
};
|
2017-10-06 19:54:17 +08:00
|
|
|
if (!SI.documentation.empty())
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
Result["documentation"] = SI.documentation;
|
|
|
|
return std::move(Result);
|
2017-10-06 19:54:17 +08:00
|
|
|
}
|
|
|
|
|
[clangd] Use operator<< to prevent printers issues in Gtest
Summary:
It is possible that there will be two different instantiations of
the printer template for a given type and some tests could end up calling the
wrong (default) one. For example, it was seen in CodeCompleteTests.cpp when
printing CompletionItems that it would use the wrong printer because the default
is also instantiated in ClangdTests.cpp.
With this change, objects that were previously printed with a custom Printer now
get printed through the operator<< which is declared alongside the class.
This rule of the thumb should make it less error-prone.
Reviewers: simark, ilya-biryukov, sammccall
Reviewed By: simark, ilya-biryukov, sammccall
Subscribers: bkramer, hokein, sammccall, klimek, ilya-biryukov, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44764
llvm-svn: 329725
2018-04-11 01:34:46 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &O,
|
|
|
|
const SignatureInformation &I) {
|
|
|
|
O << I.label << " - " << toJSON(I);
|
|
|
|
return O;
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const SignatureHelp &SH) {
|
2017-10-06 19:54:17 +08:00
|
|
|
assert(SH.activeSignature >= 0 &&
|
|
|
|
"Unexpected negative value for number of active signatures.");
|
|
|
|
assert(SH.activeParameter >= 0 &&
|
|
|
|
"Unexpected negative value for active parameter index");
|
2018-07-09 22:25:59 +08:00
|
|
|
return json::Object{
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
{"activeSignature", SH.activeSignature},
|
|
|
|
{"activeParameter", SH.activeParameter},
|
2018-07-09 22:25:59 +08:00
|
|
|
{"signatures", json::Array(SH.signatures)},
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
};
|
2017-10-06 19:54:17 +08:00
|
|
|
}
|
2017-11-09 19:30:04 +08:00
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, RenameParams &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("position", R.position) && O.map("newName", R.newName);
|
2017-11-09 19:30:04 +08:00
|
|
|
}
|
2017-12-01 05:32:29 +08:00
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
json::Value toJSON(const DocumentHighlight &DH) {
|
|
|
|
return json::Object{
|
[clangd] Document highlights for clangd
Summary: Implementation of Document Highlights Request as described in
LSP.
Contributed by William Enright (nebiroth).
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Reviewed By: malaperle
Subscribers: mgrang, sammccall, klimek, ioeric, rwols, cfe-commits, arphaman, ilya-biryukov
Differential Revision: https://reviews.llvm.org/D38425
llvm-svn: 320474
2017-12-12 20:27:47 +08:00
|
|
|
{"range", toJSON(DH.range)},
|
|
|
|
{"kind", static_cast<int>(DH.kind)},
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
[clangd] Use operator<< to prevent printers issues in Gtest
Summary:
It is possible that there will be two different instantiations of
the printer template for a given type and some tests could end up calling the
wrong (default) one. For example, it was seen in CodeCompleteTests.cpp when
printing CompletionItems that it would use the wrong printer because the default
is also instantiated in ClangdTests.cpp.
With this change, objects that were previously printed with a custom Printer now
get printed through the operator<< which is declared alongside the class.
This rule of the thumb should make it less error-prone.
Reviewers: simark, ilya-biryukov, sammccall
Reviewed By: simark, ilya-biryukov, sammccall
Subscribers: bkramer, hokein, sammccall, klimek, ilya-biryukov, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44764
llvm-svn: 329725
2018-04-11 01:34:46 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &O,
|
|
|
|
const DocumentHighlight &V) {
|
|
|
|
O << V.range;
|
|
|
|
if (V.kind == DocumentHighlightKind::Read)
|
|
|
|
O << "(r)";
|
|
|
|
if (V.kind == DocumentHighlightKind::Write)
|
|
|
|
O << "(w)";
|
|
|
|
return O;
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params, DidChangeConfigurationParams &CCP) {
|
[clangd] DidChangeConfiguration Notification
Summary:
Implementation of DidChangeConfiguration notification handling in
clangd. This currently only supports changing one setting: the path of
the compilation database to be used for the current project. In other
words, it is no longer necessary to restart clangd with a different
command line argument in order to change the compilation database.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: jkorous-apple, ioeric, simark, klimek, ilya-biryukov, arphaman, rwols, cfe-commits
Differential Revision: https://reviews.llvm.org/D39571
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325784
2018-02-22 22:00:39 +08:00
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("settings", CCP.settings);
|
|
|
|
}
|
|
|
|
|
2018-08-02 01:39:29 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params,
|
|
|
|
ClangdCompileCommand &CDbUpdate) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("workingDirectory", CDbUpdate.workingDirectory) &&
|
|
|
|
O.map("compilationCommand", CDbUpdate.compilationCommand);
|
|
|
|
}
|
|
|
|
|
2018-07-09 22:25:59 +08:00
|
|
|
bool fromJSON(const json::Value &Params,
|
|
|
|
ClangdConfigurationParamsChange &CCPC) {
|
[clangd] DidChangeConfiguration Notification
Summary:
Implementation of DidChangeConfiguration notification handling in
clangd. This currently only supports changing one setting: the path of
the compilation database to be used for the current project. In other
words, it is no longer necessary to restart clangd with a different
command line argument in order to change the compilation database.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: jkorous-apple, ioeric, simark, klimek, ilya-biryukov, arphaman, rwols, cfe-commits
Differential Revision: https://reviews.llvm.org/D39571
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325784
2018-02-22 22:00:39 +08:00
|
|
|
json::ObjectMapper O(Params);
|
2018-10-16 23:55:03 +08:00
|
|
|
return O &&
|
2018-08-02 01:39:29 +08:00
|
|
|
O.map("compilationDatabaseChanges", CCPC.compilationDatabaseChanges);
|
[clangd] DidChangeConfiguration Notification
Summary:
Implementation of DidChangeConfiguration notification handling in
clangd. This currently only supports changing one setting: the path of
the compilation database to be used for the current project. In other
words, it is no longer necessary to restart clangd with a different
command line argument in order to change the compilation database.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: jkorous-apple, ioeric, simark, klimek, ilya-biryukov, arphaman, rwols, cfe-commits
Differential Revision: https://reviews.llvm.org/D39571
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325784
2018-02-22 22:00:39 +08:00
|
|
|
}
|
|
|
|
|
2018-10-16 23:55:03 +08:00
|
|
|
bool fromJSON(const json::Value &Params, ClangdInitializationOptions &Opts) {
|
|
|
|
if (!fromJSON(Params, Opts.ParamsChange)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("compilationDatabasePath", Opts.compilationDatabasePath);
|
|
|
|
}
|
|
|
|
|
2018-09-05 19:53:07 +08:00
|
|
|
bool fromJSON(const json::Value &Params, ReferenceParams &R) {
|
|
|
|
TextDocumentPositionParams &Base = R;
|
|
|
|
return fromJSON(Params, Base);
|
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
} // namespace clangd
|
|
|
|
} // namespace clang
|