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.
|
|
|
|
// FIXME: This is extremely repetetive and ugly. Is there a better way?
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "Protocol.h"
|
2017-09-18 23:02:59 +08:00
|
|
|
|
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
|
|
|
|
|
|
|
using namespace clang;
|
2017-02-07 18:28:20 +08:00
|
|
|
using namespace clang::clangd;
|
|
|
|
|
2017-11-29 19:36:46 +08:00
|
|
|
namespace {
|
|
|
|
// Helper for mapping JSON objects onto our protocol structs. Intended use:
|
|
|
|
// Optional<Result> parse(json::Expr E) {
|
|
|
|
// ObjectParser O(E);
|
|
|
|
// if (!O || !O.parse("mandatory_field", Result.MandatoryField))
|
|
|
|
// return None;
|
|
|
|
// O.parse("optional_field", Result.OptionalField);
|
|
|
|
// return Result;
|
|
|
|
// }
|
|
|
|
// FIXME: the static methods here should probably become the public parse()
|
|
|
|
// extension point. Overloading free functions allows us to uniformly handle
|
|
|
|
// enums, vectors, etc.
|
|
|
|
class ObjectParser {
|
|
|
|
public:
|
|
|
|
ObjectParser(const json::Expr &E) : O(E.asObject()) {}
|
|
|
|
|
|
|
|
// True if the expression is an object.
|
|
|
|
operator bool() { return O; }
|
|
|
|
|
|
|
|
template <typename T> bool parse(const char *Prop, T &Out) {
|
|
|
|
assert(*this && "Must check this is an object before calling parse()");
|
|
|
|
if (const json::Expr *E = O->get(Prop))
|
|
|
|
return parse(*E, Out);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Optional requires special handling, because missing keys are OK.
|
|
|
|
template <typename T> bool parse(const char *Prop, llvm::Optional<T> &Out) {
|
|
|
|
assert(*this && "Must check this is an object before calling parse()");
|
|
|
|
if (const json::Expr *E = O->get(Prop))
|
|
|
|
return parse(*E, Out);
|
|
|
|
Out = None;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
// Primitives.
|
|
|
|
static bool parse(const json::Expr &E, std::string &Out) {
|
|
|
|
if (auto S = E.asString()) {
|
|
|
|
Out = *S;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool parse(const json::Expr &E, int &Out) {
|
|
|
|
if (auto S = E.asInteger()) {
|
|
|
|
Out = *S;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool parse(const json::Expr &E, bool &Out) {
|
|
|
|
if (auto S = E.asBoolean()) {
|
|
|
|
Out = *S;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Types with a parse() function.
|
|
|
|
template <typename T> static bool parse(const json::Expr &E, T &Out) {
|
|
|
|
if (auto Parsed = std::remove_reference<T>::type::parse(E)) {
|
|
|
|
Out = std::move(*Parsed);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Nullable values as Optional<T>.
|
|
|
|
template <typename T>
|
|
|
|
static bool parse(const json::Expr &E, llvm::Optional<T> &Out) {
|
|
|
|
if (E.asNull()) {
|
|
|
|
Out = None;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
T Result;
|
|
|
|
if (!parse(E, Result))
|
|
|
|
return false;
|
|
|
|
Out = std::move(Result);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Array values with std::vector type.
|
|
|
|
template <typename T>
|
|
|
|
static bool parse(const json::Expr &E, std::vector<T> &Out) {
|
|
|
|
if (auto *A = E.asArray()) {
|
|
|
|
Out.clear();
|
|
|
|
Out.resize(A->size());
|
|
|
|
for (size_t I = 0; I < A->size(); ++I)
|
|
|
|
if (!parse((*A)[I], Out[I]))
|
|
|
|
return false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Object values with std::map<std::string, ?>
|
|
|
|
template <typename T>
|
|
|
|
static bool parse(const json::Expr &E, std::map<std::string, T> &Out) {
|
|
|
|
if (auto *O = E.asObject()) {
|
|
|
|
for (const auto &KV : *O)
|
|
|
|
if (!parse(KV.second, Out[StringRef(KV.first)]))
|
|
|
|
return false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Special cased enums, which can't have T::parse() functions.
|
|
|
|
// FIXME: make everything free functions so there's no special casing.
|
|
|
|
static bool parse(const json::Expr &E, TraceLevel &Out) {
|
|
|
|
if (auto S = E.asString()) {
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool parse(const json::Expr &E, FileChangeType &Out) {
|
|
|
|
if (auto T = E.asInteger()) {
|
|
|
|
if (*T < static_cast<int>(FileChangeType::Created) ||
|
|
|
|
*T > static_cast<int>(FileChangeType::Deleted))
|
|
|
|
return false;
|
|
|
|
Out = static_cast<FileChangeType>(*T);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
const json::obj *O;
|
|
|
|
};
|
|
|
|
} // namespace
|
|
|
|
|
2017-04-07 19:03:26 +08:00
|
|
|
URI URI::fromUri(llvm::StringRef uri) {
|
|
|
|
URI Result;
|
|
|
|
Result.uri = uri;
|
|
|
|
uri.consume_front("file://");
|
2017-04-21 23:51:18 +08:00
|
|
|
// Also trim authority-less URIs
|
|
|
|
uri.consume_front("file:");
|
2017-04-07 19:03:26 +08:00
|
|
|
// For Windows paths e.g. /X:
|
|
|
|
if (uri.size() > 2 && uri[0] == '/' && uri[2] == ':')
|
|
|
|
uri.consume_front("/");
|
|
|
|
// Make sure that file paths are in native separators
|
|
|
|
Result.file = llvm::sys::path::convert_to_slash(uri);
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
|
|
|
URI URI::fromFile(llvm::StringRef file) {
|
|
|
|
using namespace llvm::sys;
|
|
|
|
URI Result;
|
|
|
|
Result.file = file;
|
|
|
|
Result.uri = "file://";
|
|
|
|
// For Windows paths e.g. X:
|
|
|
|
if (file.size() > 1 && file[1] == ':')
|
|
|
|
Result.uri += "/";
|
|
|
|
// Make sure that uri paths are with posix separators
|
|
|
|
Result.uri += path::convert_to_slash(file, path::Style::posix);
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2017-11-29 19:36:46 +08:00
|
|
|
llvm::Optional<URI> URI::parse(const json::Expr &E) {
|
|
|
|
if (auto S = E.asString())
|
|
|
|
return fromUri(*S);
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
json::Expr URI::unparse(const URI &U) { return U.uri; }
|
2017-04-07 19:03:26 +08:00
|
|
|
|
2017-02-07 18:28:20 +08:00
|
|
|
llvm::Optional<TextDocumentIdentifier>
|
2017-11-28 17:37:43 +08:00
|
|
|
TextDocumentIdentifier::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
TextDocumentIdentifier R;
|
|
|
|
if (!O || !O.parse("uri", R.uri))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2017-11-28 17:37:43 +08:00
|
|
|
llvm::Optional<Position> Position::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
Position R;
|
|
|
|
if (!O || !O.parse("line", R.line) || !O.parse("character", R.character))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
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
|
|
|
json::Expr Position::unparse(const Position &P) {
|
|
|
|
return json::obj{
|
|
|
|
{"line", P.line},
|
|
|
|
{"character", P.character},
|
|
|
|
};
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2017-11-28 17:37:43 +08:00
|
|
|
llvm::Optional<Range> Range::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
Range R;
|
|
|
|
if (!O || !O.parse("start", R.start) || !O.parse("end", R.end))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
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
|
|
|
json::Expr Range::unparse(const Range &P) {
|
|
|
|
return json::obj{
|
|
|
|
{"start", P.start},
|
|
|
|
{"end", P.end},
|
|
|
|
};
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
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
|
|
|
json::Expr Location::unparse(const Location &P) {
|
|
|
|
return json::obj{
|
|
|
|
{"uri", P.uri},
|
|
|
|
{"range", P.range},
|
|
|
|
};
|
2017-06-29 00:12:10 +08:00
|
|
|
}
|
|
|
|
|
2017-02-07 18:28:20 +08:00
|
|
|
llvm::Optional<TextDocumentItem>
|
2017-11-28 17:37:43 +08:00
|
|
|
TextDocumentItem::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
TextDocumentItem R;
|
|
|
|
if (!O || !O.parse("uri", R.uri) || !O.parse("languageId", R.languageId) ||
|
|
|
|
!O.parse("version", R.version) || !O.parse("text", R.text))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2017-11-28 17:37:43 +08:00
|
|
|
llvm::Optional<Metadata> Metadata::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
Metadata R;
|
2017-11-28 17:37:43 +08:00
|
|
|
if (!O)
|
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
O.parse("extraFlags", R.extraFlags);
|
|
|
|
return R;
|
2017-07-06 16:44:54 +08:00
|
|
|
}
|
|
|
|
|
2017-11-28 17:37:43 +08:00
|
|
|
llvm::Optional<TextEdit> TextEdit::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
TextEdit R;
|
|
|
|
if (!O || !O.parse("range", R.range) || !O.parse("newText", R.newText))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
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
|
|
|
json::Expr TextEdit::unparse(const TextEdit &P) {
|
|
|
|
return json::obj{
|
|
|
|
{"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
|
|
|
}
|
|
|
|
|
2017-09-27 23:31:17 +08:00
|
|
|
llvm::Optional<InitializeParams>
|
2017-11-28 17:37:43 +08:00
|
|
|
InitializeParams::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
InitializeParams R;
|
2017-11-28 17:37:43 +08:00
|
|
|
if (!O)
|
|
|
|
return None;
|
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.
|
|
|
|
O.parse("processId", R.processId);
|
|
|
|
O.parse("rootUri", R.rootUri);
|
|
|
|
O.parse("rootPath", R.rootPath);
|
|
|
|
O.parse("trace", R.trace);
|
2017-11-28 17:37:43 +08:00
|
|
|
// initializationOptions, capabilities unused
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-09-27 23:31:17 +08:00
|
|
|
}
|
|
|
|
|
2017-02-07 18:28:20 +08:00
|
|
|
llvm::Optional<DidOpenTextDocumentParams>
|
2017-11-28 17:37:43 +08:00
|
|
|
DidOpenTextDocumentParams::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
DidOpenTextDocumentParams R;
|
|
|
|
if (!O || !O.parse("textDocument", R.textDocument) ||
|
|
|
|
!O.parse("metadata", R.metadata))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-04-10 21:31:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Optional<DidCloseTextDocumentParams>
|
2017-11-28 17:37:43 +08:00
|
|
|
DidCloseTextDocumentParams::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
DidCloseTextDocumentParams R;
|
|
|
|
if (!O || !O.parse("textDocument", R.textDocument))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Optional<DidChangeTextDocumentParams>
|
2017-11-28 17:37:43 +08:00
|
|
|
DidChangeTextDocumentParams::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
DidChangeTextDocumentParams R;
|
|
|
|
if (!O || !O.parse("textDocument", R.textDocument) ||
|
|
|
|
!O.parse("contentChanges", R.contentChanges))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2017-11-28 17:37:43 +08:00
|
|
|
llvm::Optional<FileEvent> FileEvent::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
FileEvent R;
|
|
|
|
if (!O || !O.parse("uri", R.uri) || !O.parse("type", R.type))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-10-03 02:00:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Optional<DidChangeWatchedFilesParams>
|
2017-11-28 17:37:43 +08:00
|
|
|
DidChangeWatchedFilesParams::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
DidChangeWatchedFilesParams R;
|
|
|
|
if (!O || !O.parse("changes", R.changes))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-10-03 02:00:37 +08:00
|
|
|
}
|
|
|
|
|
2017-02-07 18:28:20 +08:00
|
|
|
llvm::Optional<TextDocumentContentChangeEvent>
|
2017-11-28 17:37:43 +08:00
|
|
|
TextDocumentContentChangeEvent::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
TextDocumentContentChangeEvent R;
|
|
|
|
if (!O || !O.parse("text", R.text))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Optional<FormattingOptions>
|
2017-11-28 17:37:43 +08:00
|
|
|
FormattingOptions::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
FormattingOptions R;
|
|
|
|
if (!O || !O.parse("tabSize", R.tabSize) ||
|
|
|
|
!O.parse("insertSpaces", R.insertSpaces))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
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
|
|
|
json::Expr FormattingOptions::unparse(const FormattingOptions &P) {
|
|
|
|
return json::obj{
|
|
|
|
{"tabSize", P.tabSize},
|
|
|
|
{"insertSpaces", P.insertSpaces},
|
|
|
|
};
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Optional<DocumentRangeFormattingParams>
|
2017-11-28 17:37:43 +08:00
|
|
|
DocumentRangeFormattingParams::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
DocumentRangeFormattingParams R;
|
|
|
|
if (!O || !O.parse("textDocument", R.textDocument) ||
|
|
|
|
!O.parse("range", R.range) || !O.parse("options", R.options))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-02-16 18:49:46 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Optional<DocumentOnTypeFormattingParams>
|
2017-11-28 17:37:43 +08:00
|
|
|
DocumentOnTypeFormattingParams::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
DocumentOnTypeFormattingParams R;
|
|
|
|
if (!O || !O.parse("textDocument", R.textDocument) ||
|
|
|
|
!O.parse("position", R.position) || !O.parse("ch", R.ch) ||
|
|
|
|
!O.parse("options", R.options))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Optional<DocumentFormattingParams>
|
2017-11-28 17:37:43 +08:00
|
|
|
DocumentFormattingParams::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
DocumentFormattingParams R;
|
|
|
|
if (!O || !O.parse("textDocument", R.textDocument) ||
|
|
|
|
!O.parse("options", R.options))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
2017-03-02 00:16:29 +08:00
|
|
|
|
2017-11-28 17:37:43 +08:00
|
|
|
llvm::Optional<Diagnostic> Diagnostic::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
Diagnostic R;
|
|
|
|
if (!O || !O.parse("range", R.range) || !O.parse("message", R.message))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
O.parse("severity", R.severity);
|
|
|
|
return R;
|
2017-03-02 00:16:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Optional<CodeActionContext>
|
2017-11-28 17:37:43 +08:00
|
|
|
CodeActionContext::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
CodeActionContext R;
|
|
|
|
if (!O || !O.parse("diagnostics", R.diagnostics))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-03-02 00:16:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Optional<CodeActionParams>
|
2017-11-28 17:37:43 +08:00
|
|
|
CodeActionParams::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
CodeActionParams R;
|
|
|
|
if (!O || !O.parse("textDocument", R.textDocument) ||
|
|
|
|
!O.parse("range", R.range) || !O.parse("context", R.context))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
[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-11-28 17:37:43 +08:00
|
|
|
llvm::Optional<WorkspaceEdit> WorkspaceEdit::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
WorkspaceEdit R;
|
|
|
|
if (!O || !O.parse("changes", R.changes))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
[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
|
|
|
}
|
|
|
|
|
|
|
|
const std::string ExecuteCommandParams::CLANGD_APPLY_FIX_COMMAND =
|
|
|
|
"clangd.applyFix";
|
|
|
|
|
|
|
|
llvm::Optional<ExecuteCommandParams>
|
2017-11-28 17:37:43 +08:00
|
|
|
ExecuteCommandParams::parse(const json::Expr &Params) {
|
|
|
|
const json::obj *O = Params.asObject();
|
|
|
|
if (!O)
|
|
|
|
return None;
|
|
|
|
|
[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
|
|
|
ExecuteCommandParams Result;
|
2017-11-28 17:37:43 +08:00
|
|
|
if (auto Command = O->getString("command"))
|
|
|
|
Result.command = *Command;
|
|
|
|
auto Args = O->getArray("arguments");
|
[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-11-28 17:37:43 +08:00
|
|
|
if (Result.command == ExecuteCommandParams::CLANGD_APPLY_FIX_COMMAND) {
|
|
|
|
if (!Args || Args->size() != 1)
|
[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
|
|
|
return llvm::None;
|
2017-11-28 17:37:43 +08:00
|
|
|
if (auto Parsed = WorkspaceEdit::parse(Args->front()))
|
|
|
|
Result.workspaceEdit = std::move(*Parsed);
|
|
|
|
else
|
|
|
|
return llvm::None;
|
|
|
|
} else
|
|
|
|
return llvm::None; // 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
|
|
|
return 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
|
|
|
json::Expr WorkspaceEdit::unparse(const WorkspaceEdit &WE) {
|
|
|
|
if (!WE.changes)
|
|
|
|
return json::obj{};
|
|
|
|
json::obj FileChanges;
|
|
|
|
for (auto &Change : *WE.changes)
|
|
|
|
FileChanges[Change.first] = json::ary(Change.second);
|
|
|
|
return json::obj{{"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
|
|
|
}
|
|
|
|
|
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
|
|
|
json::Expr
|
[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
|
|
|
ApplyWorkspaceEditParams::unparse(const ApplyWorkspaceEditParams &Params) {
|
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 json::obj{{"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
|
|
|
}
|
|
|
|
|
2017-04-04 17:46:39 +08:00
|
|
|
llvm::Optional<TextDocumentPositionParams>
|
2017-11-28 17:37:43 +08:00
|
|
|
TextDocumentPositionParams::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
TextDocumentPositionParams R;
|
|
|
|
if (!O || !O.parse("textDocument", R.textDocument) ||
|
|
|
|
!O.parse("position", R.position))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-04-04 17:46:39 +08:00
|
|
|
}
|
|
|
|
|
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
|
|
|
json::Expr CompletionItem::unparse(const CompletionItem &CI) {
|
2017-04-04 17:46:39 +08:00
|
|
|
assert(!CI.label.empty() && "completion item label is required");
|
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
|
|
|
json::obj 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())
|
|
|
|
Result["additionalTextEdits"] = json::ary(CI.additionalTextEdits);
|
|
|
|
return std::move(Result);
|
2017-04-04 17:46:39 +08:00
|
|
|
}
|
2017-10-06 19:54:17 +08:00
|
|
|
|
2017-11-08 15:44:12 +08:00
|
|
|
bool clangd::operator<(const CompletionItem &L, const CompletionItem &R) {
|
|
|
|
return (L.sortText.empty() ? L.label : L.sortText) <
|
|
|
|
(R.sortText.empty() ? R.label : R.sortText);
|
|
|
|
}
|
|
|
|
|
2017-11-15 17:16:29 +08:00
|
|
|
json::Expr CompletionList::unparse(const CompletionList &L) {
|
|
|
|
return json::obj{
|
|
|
|
{"isIncomplete", L.isIncomplete},
|
|
|
|
{"items", json::ary(L.items)},
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
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
|
|
|
json::Expr ParameterInformation::unparse(const ParameterInformation &PI) {
|
2017-10-06 19:54:17 +08:00
|
|
|
assert(!PI.label.empty() && "parameter information label is required");
|
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
|
|
|
json::obj 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
|
|
|
}
|
|
|
|
|
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
|
|
|
json::Expr SignatureInformation::unparse(const SignatureInformation &SI) {
|
2017-10-06 19:54:17 +08:00
|
|
|
assert(!SI.label.empty() && "signature information label is required");
|
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
|
|
|
json::obj Result{
|
|
|
|
{"label", SI.label},
|
|
|
|
{"parameters", json::ary(SI.parameters)},
|
|
|
|
};
|
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
|
|
|
}
|
|
|
|
|
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
|
|
|
json::Expr SignatureHelp::unparse(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");
|
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 json::obj{
|
|
|
|
{"activeSignature", SH.activeSignature},
|
|
|
|
{"activeParameter", SH.activeParameter},
|
|
|
|
{"signatures", json::ary(SH.signatures)},
|
|
|
|
};
|
2017-10-06 19:54:17 +08:00
|
|
|
}
|
2017-11-09 19:30:04 +08:00
|
|
|
|
2017-11-28 17:37:43 +08:00
|
|
|
llvm::Optional<RenameParams> RenameParams::parse(const json::Expr &Params) {
|
2017-11-29 19:36:46 +08:00
|
|
|
ObjectParser O(Params);
|
|
|
|
RenameParams R;
|
|
|
|
if (!O || !O.parse("textDocument", R.textDocument) ||
|
|
|
|
!O.parse("position", R.position) || !O.parse("newName", R.newName))
|
2017-11-28 17:37:43 +08:00
|
|
|
return None;
|
2017-11-29 19:36:46 +08:00
|
|
|
return R;
|
2017-11-09 19:30:04 +08:00
|
|
|
}
|