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 "URI.h"
|
|
|
|
#include "Logger.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 {
|
2017-11-29 19:36:46 +08:00
|
|
|
|
2018-01-29 23:37:46 +08:00
|
|
|
bool fromJSON(const json::Expr &E, URIForFile &R) {
|
2017-12-01 05:32:29 +08:00
|
|
|
if (auto S = E.asString()) {
|
2018-01-29 23:37:46 +08:00
|
|
|
auto U = URI::parse(*S);
|
|
|
|
if (!U) {
|
[clangd] Pass Context implicitly using TLS.
Summary:
Instead of passing Context explicitly around, we now have a thread-local
Context object `Context::current()` which is an implicit argument to
every function.
Most manipulation of this should use the WithContextValue helper, which
augments the current Context to add a single KV pair, and restores the
old context on destruction.
Advantages are:
- less boilerplate in functions that just propagate contexts
- reading most code doesn't require understanding context at all, and
using context as values in fewer places still
- fewer options to pass the "wrong" context when it changes within a
scope (e.g. when using Span)
- contexts pass through interfaces we can't modify, such as VFS
- propagating contexts across threads was slightly tricky (e.g.
copy vs move, no move-init in lambdas), and is now encapsulated in
the threadpool
Disadvantages are all the usual TLS stuff - hidden magic, and
potential for higher memory usage on threads that don't use the
context. (In practice, it's just one pointer)
Reviewers: ilya-biryukov
Subscribers: klimek, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D42517
llvm-svn: 323872
2018-01-31 21:40:48 +08:00
|
|
|
log("Failed to parse URI " + *S + ": " + llvm::toString(U.takeError()));
|
2018-01-29 23:37:46 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (U->scheme() != "file") {
|
[clangd] Pass Context implicitly using TLS.
Summary:
Instead of passing Context explicitly around, we now have a thread-local
Context object `Context::current()` which is an implicit argument to
every function.
Most manipulation of this should use the WithContextValue helper, which
augments the current Context to add a single KV pair, and restores the
old context on destruction.
Advantages are:
- less boilerplate in functions that just propagate contexts
- reading most code doesn't require understanding context at all, and
using context as values in fewer places still
- fewer options to pass the "wrong" context when it changes within a
scope (e.g. when using Span)
- contexts pass through interfaces we can't modify, such as VFS
- propagating contexts across threads was slightly tricky (e.g.
copy vs move, no move-init in lambdas), and is now encapsulated in
the threadpool
Disadvantages are all the usual TLS stuff - hidden magic, and
potential for higher memory usage on threads that don't use the
context. (In practice, it's just one pointer)
Reviewers: ilya-biryukov
Subscribers: klimek, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D42517
llvm-svn: 323872
2018-01-31 21:40:48 +08:00
|
|
|
log("Clangd only supports 'file' URI scheme for workspace files: " + *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] Pass Context implicitly using TLS.
Summary:
Instead of passing Context explicitly around, we now have a thread-local
Context object `Context::current()` which is an implicit argument to
every function.
Most manipulation of this should use the WithContextValue helper, which
augments the current Context to add a single KV pair, and restores the
old context on destruction.
Advantages are:
- less boilerplate in functions that just propagate contexts
- reading most code doesn't require understanding context at all, and
using context as values in fewer places still
- fewer options to pass the "wrong" context when it changes within a
scope (e.g. when using Span)
- contexts pass through interfaces we can't modify, such as VFS
- propagating contexts across threads was slightly tricky (e.g.
copy vs move, no move-init in lambdas), and is now encapsulated in
the threadpool
Disadvantages are all the usual TLS stuff - hidden magic, and
potential for higher memory usage on threads that don't use the
context. (In practice, it's just one pointer)
Reviewers: ilya-biryukov
Subscribers: klimek, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D42517
llvm-svn: 323872
2018-01-31 21:40:48 +08:00
|
|
|
log(llvm::toString(Path.takeError()));
|
2018-01-30 19:23:11 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
R.file = *Path;
|
2017-12-01 05:32:29 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
2017-11-29 19:36:46 +08:00
|
|
|
}
|
|
|
|
|
2018-01-29 23:37:46 +08:00
|
|
|
json::Expr 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
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
bool fromJSON(const json::Expr &Params, TextDocumentIdentifier &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("uri", R.uri);
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
bool fromJSON(const json::Expr &Params, Position &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("line", R.line) && O.map("character", R.character);
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
json::Expr toJSON(const Position &P) {
|
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{
|
|
|
|
{"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;
|
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
bool fromJSON(const json::Expr &Params, Range &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("start", R.start) && O.map("end", R.end);
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
json::Expr toJSON(const Range &P) {
|
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{
|
|
|
|
{"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;
|
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
json::Expr toJSON(const Location &P) {
|
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{
|
|
|
|
{"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;
|
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
bool fromJSON(const json::Expr &Params, TextDocumentItem &R) {
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
bool fromJSON(const json::Expr &Params, Metadata &R) {
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
bool fromJSON(const json::Expr &Params, TextEdit &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("range", R.range) && O.map("newText", R.newText);
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
json::Expr toJSON(const TextEdit &P) {
|
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{
|
|
|
|
{"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 << " => \"";
|
|
|
|
PrintEscapedString(TE.newText, OS);
|
|
|
|
return OS << '"';
|
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
bool fromJSON(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;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const json::Expr &Params, InitializeParams &R) {
|
|
|
|
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);
|
|
|
|
O.map("trace", R.trace);
|
2017-11-28 17:37:43 +08:00
|
|
|
// initializationOptions, capabilities unused
|
2017-12-01 05:32:29 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const json::Expr &Params, DidOpenTextDocumentParams &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("metadata", R.metadata);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const json::Expr &Params, DidCloseTextDocumentParams &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const json::Expr &Params, DidChangeTextDocumentParams &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("contentChanges", R.contentChanges);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(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;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const json::Expr &Params, FileEvent &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("uri", R.uri) && O.map("type", R.type);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const json::Expr &Params, DidChangeWatchedFilesParams &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("changes", R.changes);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const json::Expr &Params, TextDocumentContentChangeEvent &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("text", R.text);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const json::Expr &Params, FormattingOptions &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("tabSize", R.tabSize) &&
|
|
|
|
O.map("insertSpaces", R.insertSpaces);
|
|
|
|
}
|
|
|
|
|
|
|
|
json::Expr toJSON(const FormattingOptions &P) {
|
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{
|
|
|
|
{"tabSize", P.tabSize},
|
|
|
|
{"insertSpaces", P.insertSpaces},
|
|
|
|
};
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
bool fromJSON(const json::Expr &Params, DocumentRangeFormattingParams &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("range", R.range) && O.map("options", R.options);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const json::Expr &Params, DocumentOnTypeFormattingParams &R) {
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const json::Expr &Params, DocumentFormattingParams &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("options", R.options);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const json::Expr &Params, Diagnostic &R) {
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const json::Expr &Params, CodeActionContext &R) {
|
|
|
|
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 << "]";
|
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
bool fromJSON(const json::Expr &Params, CodeActionParams &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("range", R.range) && O.map("context", R.context);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const json::Expr &Params, WorkspaceEdit &R) {
|
|
|
|
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";
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
bool fromJSON(const json::Expr &Params, ExecuteCommandParams &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
if (!O || !O.map("command", R.command))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
auto Args = Params.asObject()->getArray("arguments");
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
json::Expr 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)
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
json::Expr toJSON(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-12-01 05:32:29 +08:00
|
|
|
bool fromJSON(const json::Expr &Params, TextDocumentPositionParams &R) {
|
|
|
|
json::ObjectMapper O(Params);
|
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("position", R.position);
|
2017-04-04 17:46:39 +08:00
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
json::Expr toJSON(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-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);
|
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
json::Expr toJSON(const CompletionList &L) {
|
2017-11-15 17:16:29 +08:00
|
|
|
return json::obj{
|
|
|
|
{"isIncomplete", L.isIncomplete},
|
|
|
|
{"items", json::ary(L.items)},
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
json::Expr toJSON(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
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
json::Expr toJSON(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
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
json::Expr 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");
|
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-12-01 05:32:29 +08:00
|
|
|
bool fromJSON(const json::Expr &Params, RenameParams &R) {
|
|
|
|
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
|
|
|
|
[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
|
|
|
json::Expr toJSON(const DocumentHighlight &DH) {
|
|
|
|
return json::obj{
|
|
|
|
{"range", toJSON(DH.range)},
|
|
|
|
{"kind", static_cast<int>(DH.kind)},
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
} // namespace clangd
|
|
|
|
} // namespace clang
|