2017-02-07 18:28:20 +08:00
|
|
|
//===--- Protocol.cpp - Language Server Protocol Implementation -----------===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2017-02-07 18:28:20 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file contains the serialization code for the LSP structs.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "Protocol.h"
|
2018-02-16 20:20:47 +08:00
|
|
|
#include "URI.h"
|
[clangd] Move non-clang base pieces into separate support/ lib. NFCI
Summary:
This enforces layering, reduces a sprawling clangd/ directory, and makes life
easier for embedders.
Reviewers: kbobyrev
Subscribers: mgorny, ilya-biryukov, javed.absar, MaskRay, jkorous, arphaman, jfb, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D79014
2020-04-28 23:49:17 +08:00
|
|
|
#include "support/Logger.h"
|
2017-02-07 18:28:20 +08:00
|
|
|
#include "clang/Basic/LLVM.h"
|
2020-01-30 21:07:42 +08:00
|
|
|
#include "clang/Index/IndexSymbol.h"
|
2018-11-28 00:40:46 +08:00
|
|
|
#include "llvm/ADT/Hashing.h"
|
2017-02-07 18:28:20 +08:00
|
|
|
#include "llvm/ADT/SmallString.h"
|
2019-03-28 01:47:49 +08:00
|
|
|
#include "llvm/ADT/StringSwitch.h"
|
2019-05-28 18:29:58 +08:00
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
2017-02-07 18:28:20 +08:00
|
|
|
#include "llvm/Support/Format.h"
|
2017-09-18 23:02:59 +08:00
|
|
|
#include "llvm/Support/FormatVariadic.h"
|
2018-11-23 23:21:19 +08:00
|
|
|
#include "llvm/Support/JSON.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 {
|
2021-01-22 22:20:52 +08:00
|
|
|
namespace {
|
|
|
|
|
|
|
|
// Helper that doesn't treat `null` and absent fields as failures.
|
|
|
|
template <typename T>
|
|
|
|
bool mapOptOrNull(const llvm::json::Value &Params, llvm::StringLiteral Prop,
|
|
|
|
T &Out, llvm::json::Path P) {
|
|
|
|
auto *O = Params.getAsObject();
|
|
|
|
assert(O);
|
|
|
|
auto *V = O->get(Prop);
|
|
|
|
// Field is missing or null.
|
|
|
|
if (!V || V->getAsNull().hasValue())
|
|
|
|
return true;
|
|
|
|
return fromJSON(*V, Out, P.field(Prop));
|
|
|
|
}
|
|
|
|
} // namespace
|
2017-11-29 19:36:46 +08:00
|
|
|
|
[clangd] Refactor JSON-over-stdin/stdout code into Transport abstraction. (re-land r344620)
Summary:
This paves the way for alternative transports (mac XPC, maybe messagepack?),
and also generally improves layering: testing ClangdLSPServer becomes less of
a pipe dream, we split up the JSONOutput monolith, etc.
This isn't a final state, much of what remains in JSONRPCDispatcher can go away,
handlers can call reply() on the transport directly, JSONOutput can be renamed
to StreamLogger and removed, etc. But this patch is sprawling already.
The main observable change (see tests) is that hitting EOF on input is now an
error: the client should send the 'exit' notification.
This is defensible: the protocol doesn't spell this case out. Reproducing the
current behavior for all combinations of shutdown/exit/EOF clutters interfaces.
We can iterate on this if desired.
Reviewers: jkorous, ioeric, hokein
Subscribers: mgorny, ilya-biryukov, MaskRay, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D53286
llvm-svn: 344672
2018-10-17 15:32:05 +08:00
|
|
|
char LSPError::ID;
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
URIForFile URIForFile::canonicalize(llvm::StringRef AbsPath,
|
|
|
|
llvm::StringRef TUPath) {
|
|
|
|
assert(llvm::sys::path::is_absolute(AbsPath) && "the path is relative");
|
2018-11-28 18:30:42 +08:00
|
|
|
auto Resolved = URI::resolvePath(AbsPath, TUPath);
|
|
|
|
if (!Resolved) {
|
|
|
|
elog("URIForFile: failed to resolve path {0} with TU path {1}: "
|
|
|
|
"{2}.\nUsing unresolved path.",
|
|
|
|
AbsPath, TUPath, Resolved.takeError());
|
2020-01-29 03:23:46 +08:00
|
|
|
return URIForFile(std::string(AbsPath));
|
2018-11-28 18:30:42 +08:00
|
|
|
}
|
|
|
|
return URIForFile(std::move(*Resolved));
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::Expected<URIForFile> URIForFile::fromURI(const URI &U,
|
|
|
|
llvm::StringRef HintPath) {
|
2018-11-28 18:30:42 +08:00
|
|
|
auto Resolved = URI::resolve(U, HintPath);
|
|
|
|
if (!Resolved)
|
|
|
|
return Resolved.takeError();
|
|
|
|
return URIForFile(std::move(*Resolved));
|
2018-02-16 20:20:47 +08:00
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &E, URIForFile &R, llvm::json::Path P) {
|
2018-07-09 22:25:59 +08:00
|
|
|
if (auto S = E.getAsString()) {
|
2018-11-28 18:30:42 +08:00
|
|
|
auto Parsed = URI::parse(*S);
|
|
|
|
if (!Parsed) {
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
P.report("failed to parse URI");
|
2018-01-29 23:37:46 +08:00
|
|
|
return false;
|
|
|
|
}
|
2018-11-28 18:30:42 +08:00
|
|
|
if (Parsed->scheme() != "file" && Parsed->scheme() != "test") {
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
P.report("clangd only supports 'file' URI scheme for workspace files");
|
2018-01-29 23:37:46 +08:00
|
|
|
return false;
|
|
|
|
}
|
2018-11-28 18:30:42 +08:00
|
|
|
// "file" and "test" schemes do not require hint path.
|
|
|
|
auto U = URIForFile::fromURI(*Parsed, /*HintPath=*/"");
|
|
|
|
if (!U) {
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
P.report("unresolvable URI");
|
|
|
|
consumeError(U.takeError());
|
2018-01-30 19:23:11 +08:00
|
|
|
return false;
|
|
|
|
}
|
2018-11-28 18:30:42 +08:00
|
|
|
R = std::move(*U);
|
2017-12-01 05:32:29 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
2017-11-29 19:36:46 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const URIForFile &U) { return U.uri(); }
|
2017-04-07 19:03:26 +08:00
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const URIForFile &U) {
|
2018-01-29 23:37:46 +08:00
|
|
|
return OS << U.uri();
|
2017-12-20 18:26:53 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const TextDocumentIdentifier &R) {
|
|
|
|
return llvm::json::Object{{"uri", R.uri}};
|
2018-02-16 22:15:55 +08:00
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, TextDocumentIdentifier &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2017-12-01 05:32:29 +08:00
|
|
|
return O && O.map("uri", R.uri);
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2020-03-03 22:57:39 +08:00
|
|
|
llvm::json::Value toJSON(const VersionedTextDocumentIdentifier &R) {
|
|
|
|
auto Result = toJSON(static_cast<const TextDocumentIdentifier &>(R));
|
[clangd] Track document versions, include them with diags, enhance logs
Summary:
This ties to an LSP feature (diagnostic versioning) but really a lot
of the value is in being able to log what's happening with file versions
and queues more descriptively and clearly.
As such it's fairly invasive, for a logging patch :-\
Key decisions:
- at the LSP layer, we don't reqire the client to provide versions (LSP
makes it mandatory but we never enforced it). If not provided,
versions start at 0 and increment. DraftStore handles this.
- don't propagate magically using contexts, but rather manually:
addDocument -> ParseInputs -> (ParsedAST, Preamble, various callbacks)
Context-propagation would hide the versions from ClangdServer, which
would make producing good log messages hard
- within ClangdServer, treat versions as opaque and unordered.
std::string is a convenient type for this, and allows richer versions
for embedders. They're "mandatory" but "null" is a reasonable default.
Subscribers: ilya-biryukov, javed.absar, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D75582
2020-03-04 07:33:29 +08:00
|
|
|
Result.getAsObject()->try_emplace("version", R.version);
|
2020-03-03 22:57:39 +08:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const llvm::json::Value &Params,
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
VersionedTextDocumentIdentifier &R, llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
|
|
|
return fromJSON(Params, static_cast<TextDocumentIdentifier &>(R), P) && O &&
|
2020-03-03 22:57:39 +08:00
|
|
|
O.map("version", R.version);
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, Position &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2017-12-01 05:32:29 +08:00
|
|
|
return O && O.map("line", R.line) && O.map("character", R.character);
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const Position &P) {
|
|
|
|
return llvm::json::Object{
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
{"line", P.line},
|
|
|
|
{"character", P.character},
|
|
|
|
};
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const Position &P) {
|
2017-12-20 18:26:53 +08:00
|
|
|
return OS << P.line << ':' << P.character;
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, Range &R, llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2017-12-01 05:32:29 +08:00
|
|
|
return O && O.map("start", R.start) && O.map("end", R.end);
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const Range &P) {
|
|
|
|
return llvm::json::Object{
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
{"start", P.start},
|
|
|
|
{"end", P.end},
|
|
|
|
};
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const Range &R) {
|
2017-12-20 18:26:53 +08:00
|
|
|
return OS << R.start << '-' << R.end;
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const Location &P) {
|
|
|
|
return llvm::json::Object{
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
{"uri", P.uri},
|
|
|
|
{"range", P.range},
|
|
|
|
};
|
2017-06-29 00:12:10 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const Location &L) {
|
2017-12-20 18:26:53 +08:00
|
|
|
return OS << L.range << '@' << L.uri;
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, TextDocumentItem &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2017-12-01 05:32:29 +08:00
|
|
|
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
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, TextEdit &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2017-12-01 05:32:29 +08:00
|
|
|
return O && O.map("range", R.range) && O.map("newText", R.newText);
|
2017-02-07 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const TextEdit &P) {
|
|
|
|
return llvm::json::Object{
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
{"range", P.range},
|
|
|
|
{"newText", P.newText},
|
|
|
|
};
|
[clangd] Handle clangd.applyFix server-side
Summary:
When the user selects a fix-it (or any code action with commands), it is
possible to let the client forward the selected command to the server.
When the clangd.applyFix command is handled on the server, it can send a
workspace/applyEdit request to the client. This has the advantage that
the client doesn't explicitly have to know how to handle
clangd.applyFix. Therefore, the code to handle clangd.applyFix in the VS
Code extension (and any other Clangd client) is not required anymore.
Reviewers: ilya-biryukov, sammccall, Nebiroth, hokein
Reviewed By: hokein
Subscribers: ioeric, hokein, rwols, puremourning, bkramer, ilya-biryukov
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D39276
llvm-svn: 317322
2017-11-03 21:39:15 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const TextEdit &TE) {
|
2018-01-26 01:29:17 +08:00
|
|
|
OS << TE.range << " => \"";
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::printEscapedString(TE.newText, OS);
|
2018-01-26 01:29:17 +08:00
|
|
|
return OS << '"';
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &E, TraceLevel &Out, llvm::json::Path P) {
|
2018-07-09 22:25:59 +08:00
|
|
|
if (auto S = E.getAsString()) {
|
2017-12-01 05:32:29 +08:00
|
|
|
if (*S == "off") {
|
|
|
|
Out = TraceLevel::Off;
|
|
|
|
return true;
|
2020-10-20 17:23:36 +08:00
|
|
|
}
|
|
|
|
if (*S == "messages") {
|
2017-12-01 05:32:29 +08:00
|
|
|
Out = TraceLevel::Messages;
|
|
|
|
return true;
|
2020-10-20 17:23:36 +08:00
|
|
|
}
|
|
|
|
if (*S == "verbose") {
|
2017-12-01 05:32:29 +08:00
|
|
|
Out = TraceLevel::Verbose;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &E, SymbolKind &Out, llvm::json::Path P) {
|
2018-07-09 22:25:59 +08:00
|
|
|
if (auto T = E.getAsInteger()) {
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
if (*T < static_cast<int>(SymbolKind::File) ||
|
|
|
|
*T > static_cast<int>(SymbolKind::TypeParameter))
|
|
|
|
return false;
|
|
|
|
Out = static_cast<SymbolKind>(*T);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &E, SymbolKindBitset &Out,
|
|
|
|
llvm::json::Path P) {
|
2018-07-09 22:25:59 +08:00
|
|
|
if (auto *A = E.getAsArray()) {
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
for (size_t I = 0; I < A->size(); ++I) {
|
|
|
|
SymbolKind KindOut;
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
if (fromJSON((*A)[I], KindOut, P.index(I)))
|
2018-10-17 15:33:42 +08:00
|
|
|
Out.set(size_t(KindOut));
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
SymbolKind adjustKindToCapability(SymbolKind Kind,
|
2018-07-26 20:05:31 +08:00
|
|
|
SymbolKindBitset &SupportedSymbolKinds) {
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
auto KindVal = static_cast<size_t>(Kind);
|
2018-07-26 20:05:31 +08:00
|
|
|
if (KindVal >= SymbolKindMin && KindVal <= SupportedSymbolKinds.size() &&
|
|
|
|
SupportedSymbolKinds[KindVal])
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
return Kind;
|
|
|
|
|
|
|
|
switch (Kind) {
|
|
|
|
// Provide some fall backs for common kinds that are close enough.
|
|
|
|
case SymbolKind::Struct:
|
|
|
|
return SymbolKind::Class;
|
|
|
|
case SymbolKind::EnumMember:
|
|
|
|
return SymbolKind::Enum;
|
|
|
|
default:
|
|
|
|
return SymbolKind::String;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[clangd] Add support for type hierarchy (super types only for now)
Summary:
Patch by Nathan Ridge(@nridge)!
This is an LSP extension proposed here:
https://github.com/Microsoft/vscode-languageserver-node/pull/426
An example client implementation can be found here:
https://github.com/theia-ide/theia/pull/3802
Reviewers: kadircet, sammccall
Reviewed By: kadircet
Subscribers: jdoerfert, sammccall, cfe-commits, mgorny, dschaefer, simark, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet
Tags: #clang
Differential Revision: https://reviews.llvm.org/D56370
llvm-svn: 356445
2019-03-19 17:27:04 +08:00
|
|
|
SymbolKind indexSymbolKindToSymbolKind(index::SymbolKind Kind) {
|
|
|
|
switch (Kind) {
|
|
|
|
case index::SymbolKind::Unknown:
|
|
|
|
return SymbolKind::Variable;
|
|
|
|
case index::SymbolKind::Module:
|
|
|
|
return SymbolKind::Module;
|
|
|
|
case index::SymbolKind::Namespace:
|
|
|
|
return SymbolKind::Namespace;
|
|
|
|
case index::SymbolKind::NamespaceAlias:
|
|
|
|
return SymbolKind::Namespace;
|
|
|
|
case index::SymbolKind::Macro:
|
|
|
|
return SymbolKind::String;
|
|
|
|
case index::SymbolKind::Enum:
|
|
|
|
return SymbolKind::Enum;
|
|
|
|
case index::SymbolKind::Struct:
|
|
|
|
return SymbolKind::Struct;
|
|
|
|
case index::SymbolKind::Class:
|
|
|
|
return SymbolKind::Class;
|
|
|
|
case index::SymbolKind::Protocol:
|
|
|
|
return SymbolKind::Interface;
|
|
|
|
case index::SymbolKind::Extension:
|
|
|
|
return SymbolKind::Interface;
|
|
|
|
case index::SymbolKind::Union:
|
|
|
|
return SymbolKind::Class;
|
|
|
|
case index::SymbolKind::TypeAlias:
|
|
|
|
return SymbolKind::Class;
|
|
|
|
case index::SymbolKind::Function:
|
|
|
|
return SymbolKind::Function;
|
|
|
|
case index::SymbolKind::Variable:
|
|
|
|
return SymbolKind::Variable;
|
|
|
|
case index::SymbolKind::Field:
|
|
|
|
return SymbolKind::Field;
|
|
|
|
case index::SymbolKind::EnumConstant:
|
|
|
|
return SymbolKind::EnumMember;
|
|
|
|
case index::SymbolKind::InstanceMethod:
|
|
|
|
case index::SymbolKind::ClassMethod:
|
|
|
|
case index::SymbolKind::StaticMethod:
|
|
|
|
return SymbolKind::Method;
|
|
|
|
case index::SymbolKind::InstanceProperty:
|
|
|
|
case index::SymbolKind::ClassProperty:
|
|
|
|
case index::SymbolKind::StaticProperty:
|
|
|
|
return SymbolKind::Property;
|
|
|
|
case index::SymbolKind::Constructor:
|
|
|
|
case index::SymbolKind::Destructor:
|
2019-11-15 22:46:17 +08:00
|
|
|
return SymbolKind::Constructor;
|
[clangd] Add support for type hierarchy (super types only for now)
Summary:
Patch by Nathan Ridge(@nridge)!
This is an LSP extension proposed here:
https://github.com/Microsoft/vscode-languageserver-node/pull/426
An example client implementation can be found here:
https://github.com/theia-ide/theia/pull/3802
Reviewers: kadircet, sammccall
Reviewed By: kadircet
Subscribers: jdoerfert, sammccall, cfe-commits, mgorny, dschaefer, simark, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet
Tags: #clang
Differential Revision: https://reviews.llvm.org/D56370
llvm-svn: 356445
2019-03-19 17:27:04 +08:00
|
|
|
case index::SymbolKind::ConversionFunction:
|
|
|
|
return SymbolKind::Function;
|
|
|
|
case index::SymbolKind::Parameter:
|
2020-01-30 21:07:42 +08:00
|
|
|
case index::SymbolKind::NonTypeTemplateParm:
|
[clangd] Add support for type hierarchy (super types only for now)
Summary:
Patch by Nathan Ridge(@nridge)!
This is an LSP extension proposed here:
https://github.com/Microsoft/vscode-languageserver-node/pull/426
An example client implementation can be found here:
https://github.com/theia-ide/theia/pull/3802
Reviewers: kadircet, sammccall
Reviewed By: kadircet
Subscribers: jdoerfert, sammccall, cfe-commits, mgorny, dschaefer, simark, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet
Tags: #clang
Differential Revision: https://reviews.llvm.org/D56370
llvm-svn: 356445
2019-03-19 17:27:04 +08:00
|
|
|
return SymbolKind::Variable;
|
|
|
|
case index::SymbolKind::Using:
|
|
|
|
return SymbolKind::Namespace;
|
2020-01-30 21:07:42 +08:00
|
|
|
case index::SymbolKind::TemplateTemplateParm:
|
|
|
|
case index::SymbolKind::TemplateTypeParm:
|
|
|
|
return SymbolKind::TypeParameter;
|
[clangd] Add support for type hierarchy (super types only for now)
Summary:
Patch by Nathan Ridge(@nridge)!
This is an LSP extension proposed here:
https://github.com/Microsoft/vscode-languageserver-node/pull/426
An example client implementation can be found here:
https://github.com/theia-ide/theia/pull/3802
Reviewers: kadircet, sammccall
Reviewed By: kadircet
Subscribers: jdoerfert, sammccall, cfe-commits, mgorny, dschaefer, simark, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet
Tags: #clang
Differential Revision: https://reviews.llvm.org/D56370
llvm-svn: 356445
2019-03-19 17:27:04 +08:00
|
|
|
}
|
|
|
|
llvm_unreachable("invalid symbol kind");
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, ClientCapabilities &R,
|
|
|
|
llvm::json::Path P) {
|
2019-01-07 23:45:19 +08:00
|
|
|
const llvm::json::Object *O = Params.getAsObject();
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
if (!O) {
|
|
|
|
P.report("expected object");
|
2018-02-15 22:32:57 +08:00
|
|
|
return false;
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
}
|
2018-10-17 15:33:42 +08:00
|
|
|
if (auto *TextDocument = O->getObject("textDocument")) {
|
2019-07-04 15:53:12 +08:00
|
|
|
if (auto *SemanticHighlighting =
|
|
|
|
TextDocument->getObject("semanticHighlightingCapabilities")) {
|
|
|
|
if (auto SemanticHighlightingSupport =
|
|
|
|
SemanticHighlighting->getBoolean("semanticHighlighting"))
|
2020-03-24 07:31:14 +08:00
|
|
|
R.TheiaSemanticHighlighting = *SemanticHighlightingSupport;
|
2019-07-04 15:53:12 +08:00
|
|
|
}
|
2020-04-07 14:16:35 +08:00
|
|
|
if (TextDocument->getObject("semanticTokens"))
|
2020-04-01 18:02:28 +08:00
|
|
|
R.SemanticTokens = true;
|
2018-10-17 15:33:42 +08:00
|
|
|
if (auto *Diagnostics = TextDocument->getObject("publishDiagnostics")) {
|
|
|
|
if (auto CategorySupport = Diagnostics->getBoolean("categorySupport"))
|
|
|
|
R.DiagnosticCategory = *CategorySupport;
|
[clangd] Embed fixes as CodeAction, instead of clangd_fixes. Clean up serialization.
Summary:
CodeAction provides us with a standard way of representing fixes inline, so
use it, replacing our existing ad-hoc extension.
After this, it's easy to serialize diagnostics using the structured
toJSON/Protocol.h mechanism rather than assembling JSON ad-hoc.
Reviewers: hokein, arphaman
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D53391
llvm-svn: 345119
2018-10-24 15:59:38 +08:00
|
|
|
if (auto CodeActions = Diagnostics->getBoolean("codeActionsInline"))
|
|
|
|
R.DiagnosticFixes = *CodeActions;
|
2019-04-18 23:17:07 +08:00
|
|
|
if (auto RelatedInfo = Diagnostics->getBoolean("relatedInformation"))
|
|
|
|
R.DiagnosticRelatedInformation = *RelatedInfo;
|
2018-10-17 15:33:42 +08:00
|
|
|
}
|
|
|
|
if (auto *Completion = TextDocument->getObject("completion")) {
|
|
|
|
if (auto *Item = Completion->getObject("completionItem")) {
|
|
|
|
if (auto SnippetSupport = Item->getBoolean("snippetSupport"))
|
|
|
|
R.CompletionSnippets = *SnippetSupport;
|
2020-10-20 17:23:36 +08:00
|
|
|
if (const auto *DocumentationFormat =
|
|
|
|
Item->getArray("documentationFormat")) {
|
2020-04-30 16:49:32 +08:00
|
|
|
for (const auto &Format : *DocumentationFormat) {
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
if (fromJSON(Format, R.CompletionDocumentationFormat, P))
|
2020-04-30 16:49:32 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2018-10-17 15:33:42 +08:00
|
|
|
}
|
|
|
|
if (auto *ItemKind = Completion->getObject("completionItemKind")) {
|
|
|
|
if (auto *ValueSet = ItemKind->get("valueSet")) {
|
|
|
|
R.CompletionItemKinds.emplace();
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
if (!fromJSON(*ValueSet, *R.CompletionItemKinds,
|
|
|
|
P.field("textDocument")
|
|
|
|
.field("completion")
|
|
|
|
.field("completionItemKind")
|
|
|
|
.field("valueSet")))
|
2018-10-17 15:33:42 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
2019-06-18 19:57:26 +08:00
|
|
|
if (auto EditsNearCursor = Completion->getBoolean("editsNearCursor"))
|
|
|
|
R.CompletionFixes = *EditsNearCursor;
|
2018-10-17 15:33:42 +08:00
|
|
|
}
|
|
|
|
if (auto *CodeAction = TextDocument->getObject("codeAction")) {
|
|
|
|
if (CodeAction->getObject("codeActionLiteralSupport"))
|
|
|
|
R.CodeActionStructure = true;
|
|
|
|
}
|
2018-11-23 23:21:19 +08:00
|
|
|
if (auto *DocumentSymbol = TextDocument->getObject("documentSymbol")) {
|
|
|
|
if (auto HierarchicalSupport =
|
|
|
|
DocumentSymbol->getBoolean("hierarchicalDocumentSymbolSupport"))
|
|
|
|
R.HierarchicalDocumentSymbol = *HierarchicalSupport;
|
|
|
|
}
|
2019-05-29 18:01:00 +08:00
|
|
|
if (auto *Hover = TextDocument->getObject("hover")) {
|
|
|
|
if (auto *ContentFormat = Hover->getArray("contentFormat")) {
|
|
|
|
for (const auto &Format : *ContentFormat) {
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
if (fromJSON(Format, R.HoverContentFormat, P))
|
2019-05-29 18:01:00 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2019-06-04 17:36:59 +08:00
|
|
|
if (auto *Help = TextDocument->getObject("signatureHelp")) {
|
2019-07-09 01:27:15 +08:00
|
|
|
R.HasSignatureHelp = true;
|
2019-06-04 17:36:59 +08:00
|
|
|
if (auto *Info = Help->getObject("signatureInformation")) {
|
|
|
|
if (auto *Parameter = Info->getObject("parameterInformation")) {
|
|
|
|
if (auto OffsetSupport = Parameter->getBoolean("labelOffsetSupport"))
|
|
|
|
R.OffsetsInSignatureHelp = *OffsetSupport;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2019-07-24 15:49:23 +08:00
|
|
|
if (auto *Rename = TextDocument->getObject("rename")) {
|
|
|
|
if (auto RenameSupport = Rename->getBoolean("prepareSupport"))
|
|
|
|
R.RenamePrepareSupport = *RenameSupport;
|
|
|
|
}
|
2018-10-17 15:33:42 +08:00
|
|
|
}
|
|
|
|
if (auto *Workspace = O->getObject("workspace")) {
|
|
|
|
if (auto *Symbol = Workspace->getObject("symbol")) {
|
|
|
|
if (auto *SymbolKind = Symbol->getObject("symbolKind")) {
|
|
|
|
if (auto *ValueSet = SymbolKind->get("valueSet")) {
|
|
|
|
R.WorkspaceSymbolKinds.emplace();
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
if (!fromJSON(*ValueSet, *R.WorkspaceSymbolKinds,
|
|
|
|
P.field("workspace")
|
|
|
|
.field("symbol")
|
|
|
|
.field("symbolKind")
|
|
|
|
.field("valueSet")))
|
2018-10-17 15:33:42 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2021-02-26 21:44:01 +08:00
|
|
|
if (auto *SemanticTokens = Workspace->getObject("semanticTokens")) {
|
|
|
|
if (auto RefreshSupport = SemanticTokens->getBoolean("refreshSupport"))
|
|
|
|
R.SemanticTokenRefreshSupport = *RefreshSupport;
|
|
|
|
}
|
2018-10-17 15:33:42 +08:00
|
|
|
}
|
[clangd] Show background index status using LSP 3.15 work-done progress notifications
Summary:
It simply shows the completed/total items on the background queue, e.g.
indexing: 233/1000
The denominator is reset to zero every time the queue goes idle.
The protocol is fairly complicated here (requires creating a remote "progress"
resource before sending updates). We implement the full protocol, but I've added
an extension allowing it to be skipped to reduce the burden on clients - in
particular the lit test takes this shortcut.
The addition of background index progress to DiagnosticConsumer seems ridiculous
at first glance, but I believe that interface is trending in the direction of
"ClangdServer callbacks" anyway. It's due for a rename, but otherwise actually
fits.
Reviewers: kadircet, usaxena95
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, jfb, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D73218
2020-01-23 02:41:45 +08:00
|
|
|
if (auto *Window = O->getObject("window")) {
|
|
|
|
if (auto WorkDoneProgress = Window->getBoolean("workDoneProgress"))
|
|
|
|
R.WorkDoneProgress = *WorkDoneProgress;
|
|
|
|
if (auto Implicit = Window->getBoolean("implicitWorkDoneProgressCreate"))
|
|
|
|
R.ImplicitProgressCreation = *Implicit;
|
|
|
|
}
|
2021-03-11 20:43:59 +08:00
|
|
|
if (auto *General = O->getObject("general")) {
|
|
|
|
if (auto *StaleRequestSupport = General->getObject("staleRequestSupport")) {
|
|
|
|
if (auto Cancel = StaleRequestSupport->getBoolean("cancel"))
|
|
|
|
R.CancelsStaleRequests = *Cancel;
|
|
|
|
}
|
|
|
|
}
|
2019-03-28 01:47:49 +08:00
|
|
|
if (auto *OffsetEncoding = O->get("offsetEncoding")) {
|
|
|
|
R.offsetEncoding.emplace();
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
if (!fromJSON(*OffsetEncoding, *R.offsetEncoding,
|
|
|
|
P.field("offsetEncoding")))
|
2019-03-28 01:47:49 +08:00
|
|
|
return false;
|
|
|
|
}
|
2018-02-15 22:32:57 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, InitializeParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2017-11-28 17:37:43 +08:00
|
|
|
if (!O)
|
2017-12-01 05:32:29 +08:00
|
|
|
return false;
|
2017-11-29 19:36:46 +08:00
|
|
|
// We deliberately don't fail if we can't parse individual fields.
|
|
|
|
// Failing to handle a slightly malformed initialize would be a disaster.
|
2017-12-01 05:32:29 +08:00
|
|
|
O.map("processId", R.processId);
|
|
|
|
O.map("rootUri", R.rootUri);
|
|
|
|
O.map("rootPath", R.rootPath);
|
2018-02-15 22:32:57 +08:00
|
|
|
O.map("capabilities", R.capabilities);
|
2021-02-16 03:56:57 +08:00
|
|
|
if (auto *RawCaps = Params.getAsObject()->getObject("capabilities"))
|
|
|
|
R.rawCapabilities = *RawCaps;
|
2017-12-01 05:32:29 +08:00
|
|
|
O.map("trace", R.trace);
|
2018-08-01 19:28:49 +08:00
|
|
|
O.map("initializationOptions", R.initializationOptions);
|
2017-12-01 05:32:29 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
[clangd] Show background index status using LSP 3.15 work-done progress notifications
Summary:
It simply shows the completed/total items on the background queue, e.g.
indexing: 233/1000
The denominator is reset to zero every time the queue goes idle.
The protocol is fairly complicated here (requires creating a remote "progress"
resource before sending updates). We implement the full protocol, but I've added
an extension allowing it to be skipped to reduce the burden on clients - in
particular the lit test takes this shortcut.
The addition of background index progress to DiagnosticConsumer seems ridiculous
at first glance, but I believe that interface is trending in the direction of
"ClangdServer callbacks" anyway. It's due for a rename, but otherwise actually
fits.
Reviewers: kadircet, usaxena95
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, jfb, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D73218
2020-01-23 02:41:45 +08:00
|
|
|
llvm::json::Value toJSON(const WorkDoneProgressCreateParams &P) {
|
|
|
|
return llvm::json::Object{{"token", P.token}};
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::json::Value toJSON(const WorkDoneProgressBegin &P) {
|
|
|
|
llvm::json::Object Result{
|
|
|
|
{"kind", "begin"},
|
|
|
|
{"title", P.title},
|
|
|
|
};
|
|
|
|
if (P.cancellable)
|
|
|
|
Result["cancellable"] = true;
|
|
|
|
if (P.percentage)
|
|
|
|
Result["percentage"] = 0;
|
2020-03-13 06:27:08 +08:00
|
|
|
|
|
|
|
// FIXME: workaround for older gcc/clang
|
|
|
|
return std::move(Result);
|
[clangd] Show background index status using LSP 3.15 work-done progress notifications
Summary:
It simply shows the completed/total items on the background queue, e.g.
indexing: 233/1000
The denominator is reset to zero every time the queue goes idle.
The protocol is fairly complicated here (requires creating a remote "progress"
resource before sending updates). We implement the full protocol, but I've added
an extension allowing it to be skipped to reduce the burden on clients - in
particular the lit test takes this shortcut.
The addition of background index progress to DiagnosticConsumer seems ridiculous
at first glance, but I believe that interface is trending in the direction of
"ClangdServer callbacks" anyway. It's due for a rename, but otherwise actually
fits.
Reviewers: kadircet, usaxena95
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, jfb, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D73218
2020-01-23 02:41:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::json::Value toJSON(const WorkDoneProgressReport &P) {
|
|
|
|
llvm::json::Object Result{{"kind", "report"}};
|
|
|
|
if (P.cancellable)
|
|
|
|
Result["cancellable"] = *P.cancellable;
|
|
|
|
if (P.message)
|
|
|
|
Result["message"] = *P.message;
|
|
|
|
if (P.percentage)
|
|
|
|
Result["percentage"] = *P.percentage;
|
2020-03-13 06:27:08 +08:00
|
|
|
// FIXME: workaround for older gcc/clang
|
|
|
|
return std::move(Result);
|
[clangd] Show background index status using LSP 3.15 work-done progress notifications
Summary:
It simply shows the completed/total items on the background queue, e.g.
indexing: 233/1000
The denominator is reset to zero every time the queue goes idle.
The protocol is fairly complicated here (requires creating a remote "progress"
resource before sending updates). We implement the full protocol, but I've added
an extension allowing it to be skipped to reduce the burden on clients - in
particular the lit test takes this shortcut.
The addition of background index progress to DiagnosticConsumer seems ridiculous
at first glance, but I believe that interface is trending in the direction of
"ClangdServer callbacks" anyway. It's due for a rename, but otherwise actually
fits.
Reviewers: kadircet, usaxena95
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, jfb, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D73218
2020-01-23 02:41:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::json::Value toJSON(const WorkDoneProgressEnd &P) {
|
|
|
|
llvm::json::Object Result{{"kind", "end"}};
|
|
|
|
if (P.message)
|
|
|
|
Result["message"] = *P.message;
|
2020-03-13 06:27:08 +08:00
|
|
|
// FIXME: workaround for older gcc/clang
|
|
|
|
return std::move(Result);
|
[clangd] Show background index status using LSP 3.15 work-done progress notifications
Summary:
It simply shows the completed/total items on the background queue, e.g.
indexing: 233/1000
The denominator is reset to zero every time the queue goes idle.
The protocol is fairly complicated here (requires creating a remote "progress"
resource before sending updates). We implement the full protocol, but I've added
an extension allowing it to be skipped to reduce the burden on clients - in
particular the lit test takes this shortcut.
The addition of background index progress to DiagnosticConsumer seems ridiculous
at first glance, but I believe that interface is trending in the direction of
"ClangdServer callbacks" anyway. It's due for a rename, but otherwise actually
fits.
Reviewers: kadircet, usaxena95
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, jfb, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D73218
2020-01-23 02:41:45 +08:00
|
|
|
}
|
|
|
|
|
2019-06-18 21:37:54 +08:00
|
|
|
llvm::json::Value toJSON(const MessageType &R) {
|
|
|
|
return static_cast<int64_t>(R);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::json::Value toJSON(const ShowMessageParams &R) {
|
|
|
|
return llvm::json::Object{{"type", R.type}, {"message", R.message}};
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, DidOpenTextDocumentParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2018-11-02 21:06:55 +08:00
|
|
|
return O && O.map("textDocument", R.textDocument);
|
2017-12-01 05:32:29 +08:00
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, DidCloseTextDocumentParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2017-12-01 05:32:29 +08:00
|
|
|
return O && O.map("textDocument", R.textDocument);
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, DidSaveTextDocumentParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2020-04-10 09:27:37 +08:00
|
|
|
return O && O.map("textDocument", R.textDocument);
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, DidChangeTextDocumentParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2020-10-09 22:06:46 +08:00
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
2018-02-23 02:40:39 +08:00
|
|
|
O.map("contentChanges", R.contentChanges) &&
|
2020-10-09 22:06:46 +08:00
|
|
|
O.map("wantDiagnostics", R.wantDiagnostics) &&
|
2021-01-22 22:20:52 +08:00
|
|
|
mapOptOrNull(Params, "forceRebuild", R.forceRebuild, P);
|
2017-12-01 05:32:29 +08:00
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &E, FileChangeType &Out,
|
|
|
|
llvm::json::Path P) {
|
2018-07-09 22:25:59 +08:00
|
|
|
if (auto T = E.getAsInteger()) {
|
2017-12-01 05:32:29 +08:00
|
|
|
if (*T < static_cast<int>(FileChangeType::Created) ||
|
|
|
|
*T > static_cast<int>(FileChangeType::Deleted))
|
|
|
|
return false;
|
|
|
|
Out = static_cast<FileChangeType>(*T);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, FileEvent &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2017-12-01 05:32:29 +08:00
|
|
|
return O && O.map("uri", R.uri) && O.map("type", R.type);
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, DidChangeWatchedFilesParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2017-12-01 05:32:29 +08:00
|
|
|
return O && O.map("changes", R.changes);
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params,
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
TextDocumentContentChangeEvent &R, llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
[clangd] Support incremental document syncing
Summary:
This patch adds support for incremental document syncing, as described
in the LSP spec. The protocol specifies ranges in terms of Position (a
line and a character), and our drafts are stored as plain strings. So I
see two things that may not be super efficient for very large files:
- Converting a Position to an offset (the positionToOffset function)
requires searching for end of lines until we reach the desired line.
- When we update a range, we construct a new string, which implies
copying the whole document.
However, for the typical size of a C++ document and the frequency of
update (at which a user types), it may not be an issue. This patch aims
at getting the basic feature in, and we can always improve it later if
we find it's too slow.
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Reviewers: malaperle, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: MaskRay, klimek, mgorny, ilya-biryukov, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D44272
llvm-svn: 328500
2018-03-26 22:41:40 +08:00
|
|
|
return O && O.map("range", R.range) && O.map("rangeLength", R.rangeLength) &&
|
|
|
|
O.map("text", R.text);
|
2017-12-01 05:32:29 +08:00
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, DocumentRangeFormattingParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2019-07-13 11:24:48 +08:00
|
|
|
return O && O.map("textDocument", R.textDocument) && O.map("range", R.range);
|
2017-12-01 05:32:29 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params,
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
DocumentOnTypeFormattingParams &R, llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2017-12-01 05:32:29 +08:00
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
2019-06-10 21:01:49 +08:00
|
|
|
O.map("position", R.position) && O.map("ch", R.ch);
|
2017-12-01 05:32:29 +08:00
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, DocumentFormattingParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2019-06-10 21:01:49 +08:00
|
|
|
return O && O.map("textDocument", R.textDocument);
|
2017-12-01 05:32:29 +08:00
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, DocumentSymbolParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2018-07-06 03:35:01 +08:00
|
|
|
return O && O.map("textDocument", R.textDocument);
|
|
|
|
}
|
|
|
|
|
2019-04-18 23:17:07 +08:00
|
|
|
llvm::json::Value toJSON(const DiagnosticRelatedInformation &DRI) {
|
|
|
|
return llvm::json::Object{
|
2019-07-13 11:24:48 +08:00
|
|
|
{"location", DRI.location},
|
|
|
|
{"message", DRI.message},
|
2019-04-18 23:17:07 +08:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const Diagnostic &D) {
|
|
|
|
llvm::json::Object Diag{
|
2018-10-17 00:29:41 +08:00
|
|
|
{"range", D.range},
|
|
|
|
{"severity", D.severity},
|
|
|
|
{"message", D.message},
|
|
|
|
};
|
[clangd] Embed fixes as CodeAction, instead of clangd_fixes. Clean up serialization.
Summary:
CodeAction provides us with a standard way of representing fixes inline, so
use it, replacing our existing ad-hoc extension.
After this, it's easy to serialize diagnostics using the structured
toJSON/Protocol.h mechanism rather than assembling JSON ad-hoc.
Reviewers: hokein, arphaman
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D53391
llvm-svn: 345119
2018-10-24 15:59:38 +08:00
|
|
|
if (D.category)
|
|
|
|
Diag["category"] = *D.category;
|
|
|
|
if (D.codeActions)
|
|
|
|
Diag["codeActions"] = D.codeActions;
|
2019-04-17 20:35:16 +08:00
|
|
|
if (!D.code.empty())
|
|
|
|
Diag["code"] = D.code;
|
|
|
|
if (!D.source.empty())
|
|
|
|
Diag["source"] = D.source;
|
2019-04-18 23:17:07 +08:00
|
|
|
if (D.relatedInformation)
|
|
|
|
Diag["relatedInformation"] = *D.relatedInformation;
|
2020-03-13 06:27:08 +08:00
|
|
|
// FIXME: workaround for older gcc/clang
|
2018-10-17 00:29:41 +08:00
|
|
|
return std::move(Diag);
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, Diagnostic &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2020-10-09 22:06:46 +08:00
|
|
|
return O && O.map("range", R.range) && O.map("message", R.message) &&
|
2021-01-22 22:20:52 +08:00
|
|
|
mapOptOrNull(Params, "severity", R.severity, P) &&
|
|
|
|
mapOptOrNull(Params, "category", R.category, P) &&
|
|
|
|
mapOptOrNull(Params, "code", R.code, P) &&
|
|
|
|
mapOptOrNull(Params, "source", R.source, P);
|
2017-12-01 05:32:29 +08:00
|
|
|
}
|
|
|
|
|
2020-03-03 19:44:40 +08:00
|
|
|
llvm::json::Value toJSON(const PublishDiagnosticsParams &PDP) {
|
2020-05-11 05:29:27 +08:00
|
|
|
llvm::json::Object Result{
|
[clangd] Track document versions, include them with diags, enhance logs
Summary:
This ties to an LSP feature (diagnostic versioning) but really a lot
of the value is in being able to log what's happening with file versions
and queues more descriptively and clearly.
As such it's fairly invasive, for a logging patch :-\
Key decisions:
- at the LSP layer, we don't reqire the client to provide versions (LSP
makes it mandatory but we never enforced it). If not provided,
versions start at 0 and increment. DraftStore handles this.
- don't propagate magically using contexts, but rather manually:
addDocument -> ParseInputs -> (ParsedAST, Preamble, various callbacks)
Context-propagation would hide the versions from ClangdServer, which
would make producing good log messages hard
- within ClangdServer, treat versions as opaque and unordered.
std::string is a convenient type for this, and allows richer versions
for embedders. They're "mandatory" but "null" is a reasonable default.
Subscribers: ilya-biryukov, javed.absar, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D75582
2020-03-04 07:33:29 +08:00
|
|
|
{"uri", PDP.uri},
|
|
|
|
{"diagnostics", PDP.diagnostics},
|
2020-03-03 19:44:40 +08:00
|
|
|
};
|
2020-05-11 05:29:27 +08:00
|
|
|
if (PDP.version)
|
|
|
|
Result["version"] = PDP.version;
|
|
|
|
return std::move(Result);
|
2020-03-03 19:44:40 +08:00
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, CodeActionContext &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2020-10-09 21:17:26 +08:00
|
|
|
if (!O || !O.map("diagnostics", R.diagnostics))
|
|
|
|
return false;
|
|
|
|
O.map("only", R.only);
|
|
|
|
return true;
|
2017-12-01 05:32:29 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const Diagnostic &D) {
|
2018-01-26 01:29:17 +08:00
|
|
|
OS << D.range << " [";
|
|
|
|
switch (D.severity) {
|
2019-01-03 21:28:05 +08:00
|
|
|
case 1:
|
|
|
|
OS << "error";
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
OS << "warning";
|
|
|
|
break;
|
|
|
|
case 3:
|
|
|
|
OS << "note";
|
|
|
|
break;
|
|
|
|
case 4:
|
|
|
|
OS << "remark";
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
OS << "diagnostic";
|
|
|
|
break;
|
2018-01-26 01:29:17 +08:00
|
|
|
}
|
|
|
|
return OS << '(' << D.severity << "): " << D.message << "]";
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, CodeActionParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2017-12-01 05:32:29 +08:00
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("range", R.range) && O.map("context", R.context);
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, WorkspaceEdit &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2017-12-01 05:32:29 +08:00
|
|
|
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
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, ExecuteCommandParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2017-12-01 05:32:29 +08:00
|
|
|
if (!O || !O.map("command", R.command))
|
|
|
|
return false;
|
|
|
|
|
2021-02-11 23:32:09 +08:00
|
|
|
const auto *Args = Params.getAsObject()->get("arguments");
|
|
|
|
if (!Args)
|
|
|
|
return true; // Missing args is ok, argument is null.
|
|
|
|
const auto *ArgsArray = Args->getAsArray();
|
|
|
|
if (!ArgsArray) {
|
|
|
|
P.field("arguments").report("expected array");
|
|
|
|
return false;
|
2017-12-01 05:32:29 +08:00
|
|
|
}
|
2021-02-11 23:32:09 +08:00
|
|
|
if (ArgsArray->size() > 1) {
|
|
|
|
P.field("arguments").report("Command should have 0 or 1 argument");
|
|
|
|
return false;
|
|
|
|
} else if (ArgsArray->size() == 1) {
|
|
|
|
R.argument = ArgsArray->front();
|
|
|
|
}
|
|
|
|
return true;
|
[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
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const SymbolInformation &P) {
|
2020-10-06 03:41:35 +08:00
|
|
|
llvm::json::Object O{
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
{"name", P.name},
|
|
|
|
{"kind", static_cast<int>(P.kind)},
|
|
|
|
{"location", P.location},
|
|
|
|
{"containerName", P.containerName},
|
|
|
|
};
|
2020-10-06 03:41:35 +08:00
|
|
|
if (P.score)
|
|
|
|
O["score"] = *P.score;
|
|
|
|
return std::move(O);
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &O,
|
|
|
|
const SymbolInformation &SI) {
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
O << SI.containerName << "::" << SI.name << " - " << toJSON(SI);
|
|
|
|
return O;
|
|
|
|
}
|
|
|
|
|
2018-11-28 00:40:46 +08:00
|
|
|
bool operator==(const SymbolDetails &LHS, const SymbolDetails &RHS) {
|
|
|
|
return LHS.name == RHS.name && LHS.containerName == RHS.containerName &&
|
|
|
|
LHS.USR == RHS.USR && LHS.ID == RHS.ID;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::json::Value toJSON(const SymbolDetails &P) {
|
2019-01-25 23:14:03 +08:00
|
|
|
llvm::json::Object Result{{"name", llvm::json::Value(nullptr)},
|
2019-01-07 23:45:19 +08:00
|
|
|
{"containerName", llvm::json::Value(nullptr)},
|
|
|
|
{"usr", llvm::json::Value(nullptr)},
|
|
|
|
{"id", llvm::json::Value(nullptr)}};
|
2018-11-28 00:40:46 +08:00
|
|
|
|
|
|
|
if (!P.name.empty())
|
2019-01-25 23:14:03 +08:00
|
|
|
Result["name"] = P.name;
|
2018-11-28 00:40:46 +08:00
|
|
|
|
|
|
|
if (!P.containerName.empty())
|
2019-01-25 23:14:03 +08:00
|
|
|
Result["containerName"] = P.containerName;
|
2018-11-28 00:40:46 +08:00
|
|
|
|
|
|
|
if (!P.USR.empty())
|
2019-01-25 23:14:03 +08:00
|
|
|
Result["usr"] = P.USR;
|
2018-11-28 00:40:46 +08:00
|
|
|
|
2020-10-29 23:04:53 +08:00
|
|
|
if (P.ID)
|
|
|
|
Result["id"] = P.ID.str();
|
2018-11-28 00:40:46 +08:00
|
|
|
|
2020-03-13 06:27:08 +08:00
|
|
|
// FIXME: workaround for older gcc/clang
|
|
|
|
return std::move(Result);
|
2018-11-28 00:40:46 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &O, const SymbolDetails &S) {
|
|
|
|
if (!S.containerName.empty()) {
|
|
|
|
O << S.containerName;
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::StringRef ContNameRef;
|
2018-11-28 00:40:46 +08:00
|
|
|
if (!ContNameRef.endswith("::")) {
|
|
|
|
O << " ";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
O << S.name << " - " << toJSON(S);
|
|
|
|
return O;
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, WorkspaceSymbolParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2021-03-03 05:16:29 +08:00
|
|
|
return O && O.map("query", R.query) &&
|
|
|
|
mapOptOrNull(Params, "limit", R.limit, P);
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const Command &C) {
|
|
|
|
auto Cmd = llvm::json::Object{{"title", C.title}, {"command", C.command}};
|
2021-02-11 23:32:09 +08:00
|
|
|
if (!C.argument.getAsNull())
|
|
|
|
Cmd["arguments"] = llvm::json::Array{C.argument};
|
2018-02-16 22:15:55 +08:00
|
|
|
return std::move(Cmd);
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
const llvm::StringLiteral CodeAction::QUICKFIX_KIND = "quickfix";
|
[clangd] Interfaces for writing code tweaks
Summary:
The code tweaks are an implementation of mini-refactorings exposed
via the LSP code actions. They run in two stages:
- Stage 1. Decides whether the action is available to the user and
collects all the information required to finish the action.
Should be cheap, since this will run over all the actions known to
clangd on each textDocument/codeAction request from the client.
- Stage 2. Uses information from stage 1 to produce the actual edits
that the code action should perform. This stage can be expensive and
will only run if the user chooses to perform the specified action in
the UI.
One unfortunate consequence of this change is increased latency of
processing the textDocument/codeAction requests, which now wait for an
AST. However, we cannot avoid this with what we have available in the LSP
today.
Reviewers: kadircet, ioeric, hokein, sammccall
Reviewed By: sammccall
Subscribers: mgrang, mgorny, MaskRay, jkorous, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D56267
llvm-svn: 352494
2019-01-29 22:17:36 +08:00
|
|
|
const llvm::StringLiteral CodeAction::REFACTOR_KIND = "refactor";
|
2019-06-18 21:37:54 +08:00
|
|
|
const llvm::StringLiteral CodeAction::INFO_KIND = "info";
|
2018-10-17 00:29:41 +08:00
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const CodeAction &CA) {
|
|
|
|
auto CodeAction = llvm::json::Object{{"title", CA.title}};
|
2018-10-17 00:29:41 +08:00
|
|
|
if (CA.kind)
|
|
|
|
CodeAction["kind"] = *CA.kind;
|
|
|
|
if (CA.diagnostics)
|
2019-01-07 23:45:19 +08:00
|
|
|
CodeAction["diagnostics"] = llvm::json::Array(*CA.diagnostics);
|
2020-09-29 22:28:50 +08:00
|
|
|
if (CA.isPreferred)
|
|
|
|
CodeAction["isPreferred"] = true;
|
2018-10-17 00:29:41 +08:00
|
|
|
if (CA.edit)
|
|
|
|
CodeAction["edit"] = *CA.edit;
|
|
|
|
if (CA.command)
|
|
|
|
CodeAction["command"] = *CA.command;
|
|
|
|
return std::move(CodeAction);
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &O, const DocumentSymbol &S) {
|
2018-11-23 23:21:19 +08:00
|
|
|
return O << S.name << " - " << toJSON(S);
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const DocumentSymbol &S) {
|
|
|
|
llvm::json::Object Result{{"name", S.name},
|
|
|
|
{"kind", static_cast<int>(S.kind)},
|
|
|
|
{"range", S.range},
|
|
|
|
{"selectionRange", S.selectionRange}};
|
2018-11-23 23:21:19 +08:00
|
|
|
|
|
|
|
if (!S.detail.empty())
|
|
|
|
Result["detail"] = S.detail;
|
|
|
|
if (!S.children.empty())
|
|
|
|
Result["children"] = S.children;
|
|
|
|
if (S.deprecated)
|
|
|
|
Result["deprecated"] = true;
|
2020-03-13 06:27:08 +08:00
|
|
|
// FIXME: workaround for older gcc/clang
|
|
|
|
return std::move(Result);
|
2018-11-23 23:21:19 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const WorkspaceEdit &WE) {
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
if (!WE.changes)
|
2019-01-07 23:45:19 +08:00
|
|
|
return llvm::json::Object{};
|
|
|
|
llvm::json::Object FileChanges;
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
for (auto &Change : *WE.changes)
|
2019-01-07 23:45:19 +08:00
|
|
|
FileChanges[Change.first] = llvm::json::Array(Change.second);
|
|
|
|
return llvm::json::Object{{"changes", std::move(FileChanges)}};
|
[clangd] Handle clangd.applyFix server-side
Summary:
When the user selects a fix-it (or any code action with commands), it is
possible to let the client forward the selected command to the server.
When the clangd.applyFix command is handled on the server, it can send a
workspace/applyEdit request to the client. This has the advantage that
the client doesn't explicitly have to know how to handle
clangd.applyFix. Therefore, the code to handle clangd.applyFix in the VS
Code extension (and any other Clangd client) is not required anymore.
Reviewers: ilya-biryukov, sammccall, Nebiroth, hokein
Reviewed By: hokein
Subscribers: ioeric, hokein, rwols, puremourning, bkramer, ilya-biryukov
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D39276
llvm-svn: 317322
2017-11-03 21:39:15 +08:00
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, TweakArgs &A,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
[clangd] Interfaces for writing code tweaks
Summary:
The code tweaks are an implementation of mini-refactorings exposed
via the LSP code actions. They run in two stages:
- Stage 1. Decides whether the action is available to the user and
collects all the information required to finish the action.
Should be cheap, since this will run over all the actions known to
clangd on each textDocument/codeAction request from the client.
- Stage 2. Uses information from stage 1 to produce the actual edits
that the code action should perform. This stage can be expensive and
will only run if the user chooses to perform the specified action in
the UI.
One unfortunate consequence of this change is increased latency of
processing the textDocument/codeAction requests, which now wait for an
AST. However, we cannot avoid this with what we have available in the LSP
today.
Reviewers: kadircet, ioeric, hokein, sammccall
Reviewed By: sammccall
Subscribers: mgrang, mgorny, MaskRay, jkorous, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D56267
llvm-svn: 352494
2019-01-29 22:17:36 +08:00
|
|
|
return O && O.map("file", A.file) && O.map("selection", A.selection) &&
|
|
|
|
O.map("tweakID", A.tweakID);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::json::Value toJSON(const TweakArgs &A) {
|
|
|
|
return llvm::json::Object{
|
|
|
|
{"tweakID", A.tweakID}, {"selection", A.selection}, {"file", A.file}};
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const ApplyWorkspaceEditParams &Params) {
|
|
|
|
return llvm::json::Object{{"edit", Params.edit}};
|
[clangd] Handle clangd.applyFix server-side
Summary:
When the user selects a fix-it (or any code action with commands), it is
possible to let the client forward the selected command to the server.
When the clangd.applyFix command is handled on the server, it can send a
workspace/applyEdit request to the client. This has the advantage that
the client doesn't explicitly have to know how to handle
clangd.applyFix. Therefore, the code to handle clangd.applyFix in the VS
Code extension (and any other Clangd client) is not required anymore.
Reviewers: ilya-biryukov, sammccall, Nebiroth, hokein
Reviewed By: hokein
Subscribers: ioeric, hokein, rwols, puremourning, bkramer, ilya-biryukov
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D39276
llvm-svn: 317322
2017-11-03 21:39:15 +08:00
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Response, ApplyWorkspaceEditResponse &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Response, P);
|
2020-10-09 22:06:46 +08:00
|
|
|
return O && O.map("applied", R.applied) &&
|
|
|
|
O.map("failureReason", R.failureReason);
|
2019-08-05 20:48:09 +08:00
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, TextDocumentPositionParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2017-12-01 05:32:29 +08:00
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("position", R.position);
|
2017-04-04 17:46:39 +08:00
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, CompletionContext &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2019-01-25 23:14:03 +08:00
|
|
|
int TriggerKind;
|
2020-10-09 22:06:46 +08:00
|
|
|
if (!O || !O.map("triggerKind", TriggerKind) ||
|
2021-01-22 22:20:52 +08:00
|
|
|
!mapOptOrNull(Params, "triggerCharacter", R.triggerCharacter, P))
|
2019-01-03 21:37:12 +08:00
|
|
|
return false;
|
2019-01-25 23:14:03 +08:00
|
|
|
R.triggerKind = static_cast<CompletionTriggerKind>(TriggerKind);
|
2019-01-03 21:37:12 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, CompletionParams &R,
|
|
|
|
llvm::json::Path P) {
|
2021-03-03 05:16:29 +08:00
|
|
|
if (!fromJSON(Params, static_cast<TextDocumentPositionParams &>(R), P) ||
|
|
|
|
!mapOptOrNull(Params, "limit", R.limit, P))
|
2019-01-03 21:37:12 +08:00
|
|
|
return false;
|
|
|
|
if (auto *Context = Params.getAsObject()->get("context"))
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
return fromJSON(*Context, R.context, P.field("context"));
|
2019-01-03 21:37:12 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
static llvm::StringRef toTextKind(MarkupKind Kind) {
|
[clangd] Implement textDocument/hover
Summary: Implemention of textDocument/hover as described in LSP definition.
This patch adds a basic Hover implementation. When hovering a variable,
function, method or namespace, clangd will return a text containing the
declaration's scope, as well as the declaration of the hovered entity.
For example, for a variable:
Declared in class Foo::Bar
int hello = 2
For macros, the macro definition is returned.
This patch doesn't include:
- markdown support (the client I use doesn't support it yet)
- range support (optional in the Hover response)
- comments associated to variables/functions/classes
They are kept as future work to keep this patch simpler.
I added tests in XRefsTests.cpp. hover.test contains one simple
smoketest to make sure the feature works from a black box perspective.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: sammccall, mgrang, klimek, rwols, ilya-biryukov, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D35894
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325395
2018-02-17 05:38:15 +08:00
|
|
|
switch (Kind) {
|
|
|
|
case MarkupKind::PlainText:
|
|
|
|
return "plaintext";
|
|
|
|
case MarkupKind::Markdown:
|
|
|
|
return "markdown";
|
|
|
|
}
|
|
|
|
llvm_unreachable("Invalid MarkupKind");
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &V, MarkupKind &K, llvm::json::Path P) {
|
2019-05-29 18:01:00 +08:00
|
|
|
auto Str = V.getAsString();
|
|
|
|
if (!Str) {
|
2020-10-09 22:08:44 +08:00
|
|
|
P.report("expected string");
|
2019-05-29 18:01:00 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (*Str == "plaintext")
|
|
|
|
K = MarkupKind::PlainText;
|
|
|
|
else if (*Str == "markdown")
|
|
|
|
K = MarkupKind::Markdown;
|
|
|
|
else {
|
2020-10-09 22:08:44 +08:00
|
|
|
P.report("unknown markup kind");
|
2019-05-29 18:01:00 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, MarkupKind K) {
|
|
|
|
return OS << toTextKind(K);
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const MarkupContent &MC) {
|
2018-02-17 07:12:26 +08:00
|
|
|
if (MC.value.empty())
|
[clangd] Implement textDocument/hover
Summary: Implemention of textDocument/hover as described in LSP definition.
This patch adds a basic Hover implementation. When hovering a variable,
function, method or namespace, clangd will return a text containing the
declaration's scope, as well as the declaration of the hovered entity.
For example, for a variable:
Declared in class Foo::Bar
int hello = 2
For macros, the macro definition is returned.
This patch doesn't include:
- markdown support (the client I use doesn't support it yet)
- range support (optional in the Hover response)
- comments associated to variables/functions/classes
They are kept as future work to keep this patch simpler.
I added tests in XRefsTests.cpp. hover.test contains one simple
smoketest to make sure the feature works from a black box perspective.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: sammccall, mgrang, klimek, rwols, ilya-biryukov, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D35894
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325395
2018-02-17 05:38:15 +08:00
|
|
|
return nullptr;
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
return llvm::json::Object{
|
2018-02-17 07:12:26 +08:00
|
|
|
{"kind", toTextKind(MC.kind)},
|
|
|
|
{"value", MC.value},
|
[clangd] Implement textDocument/hover
Summary: Implemention of textDocument/hover as described in LSP definition.
This patch adds a basic Hover implementation. When hovering a variable,
function, method or namespace, clangd will return a text containing the
declaration's scope, as well as the declaration of the hovered entity.
For example, for a variable:
Declared in class Foo::Bar
int hello = 2
For macros, the macro definition is returned.
This patch doesn't include:
- markdown support (the client I use doesn't support it yet)
- range support (optional in the Hover response)
- comments associated to variables/functions/classes
They are kept as future work to keep this patch simpler.
I added tests in XRefsTests.cpp. hover.test contains one simple
smoketest to make sure the feature works from a black box perspective.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: sammccall, mgrang, klimek, rwols, ilya-biryukov, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D35894
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325395
2018-02-17 05:38:15 +08:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const Hover &H) {
|
|
|
|
llvm::json::Object Result{{"contents", toJSON(H.contents)}};
|
[clangd] Implement textDocument/hover
Summary: Implemention of textDocument/hover as described in LSP definition.
This patch adds a basic Hover implementation. When hovering a variable,
function, method or namespace, clangd will return a text containing the
declaration's scope, as well as the declaration of the hovered entity.
For example, for a variable:
Declared in class Foo::Bar
int hello = 2
For macros, the macro definition is returned.
This patch doesn't include:
- markdown support (the client I use doesn't support it yet)
- range support (optional in the Hover response)
- comments associated to variables/functions/classes
They are kept as future work to keep this patch simpler.
I added tests in XRefsTests.cpp. hover.test contains one simple
smoketest to make sure the feature works from a black box perspective.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: sammccall, mgrang, klimek, rwols, ilya-biryukov, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D35894
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325395
2018-02-17 05:38:15 +08:00
|
|
|
|
2018-02-17 07:12:26 +08:00
|
|
|
if (H.range.hasValue())
|
|
|
|
Result["range"] = toJSON(*H.range);
|
[clangd] Implement textDocument/hover
Summary: Implemention of textDocument/hover as described in LSP definition.
This patch adds a basic Hover implementation. When hovering a variable,
function, method or namespace, clangd will return a text containing the
declaration's scope, as well as the declaration of the hovered entity.
For example, for a variable:
Declared in class Foo::Bar
int hello = 2
For macros, the macro definition is returned.
This patch doesn't include:
- markdown support (the client I use doesn't support it yet)
- range support (optional in the Hover response)
- comments associated to variables/functions/classes
They are kept as future work to keep this patch simpler.
I added tests in XRefsTests.cpp. hover.test contains one simple
smoketest to make sure the feature works from a black box perspective.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: sammccall, mgrang, klimek, rwols, ilya-biryukov, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D35894
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325395
2018-02-17 05:38:15 +08:00
|
|
|
|
|
|
|
return std::move(Result);
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &E, CompletionItemKind &Out,
|
|
|
|
llvm::json::Path P) {
|
2018-09-28 01:13:07 +08:00
|
|
|
if (auto T = E.getAsInteger()) {
|
|
|
|
if (*T < static_cast<int>(CompletionItemKind::Text) ||
|
|
|
|
*T > static_cast<int>(CompletionItemKind::TypeParameter))
|
|
|
|
return false;
|
|
|
|
Out = static_cast<CompletionItemKind>(*T);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
CompletionItemKind
|
|
|
|
adjustKindToCapability(CompletionItemKind Kind,
|
2019-01-25 23:14:03 +08:00
|
|
|
CompletionItemKindBitset &SupportedCompletionItemKinds) {
|
2018-09-28 01:13:07 +08:00
|
|
|
auto KindVal = static_cast<size_t>(Kind);
|
|
|
|
if (KindVal >= CompletionItemKindMin &&
|
2019-01-25 23:14:03 +08:00
|
|
|
KindVal <= SupportedCompletionItemKinds.size() &&
|
|
|
|
SupportedCompletionItemKinds[KindVal])
|
2018-09-28 01:13:07 +08:00
|
|
|
return Kind;
|
|
|
|
|
|
|
|
switch (Kind) {
|
|
|
|
// Provide some fall backs for common kinds that are close enough.
|
|
|
|
case CompletionItemKind::Folder:
|
|
|
|
return CompletionItemKind::File;
|
|
|
|
case CompletionItemKind::EnumMember:
|
|
|
|
return CompletionItemKind::Enum;
|
|
|
|
case CompletionItemKind::Struct:
|
|
|
|
return CompletionItemKind::Class;
|
|
|
|
default:
|
|
|
|
return CompletionItemKind::Text;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &E, CompletionItemKindBitset &Out,
|
|
|
|
llvm::json::Path P) {
|
2018-09-28 01:13:07 +08:00
|
|
|
if (auto *A = E.getAsArray()) {
|
|
|
|
for (size_t I = 0; I < A->size(); ++I) {
|
|
|
|
CompletionItemKind KindOut;
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
if (fromJSON((*A)[I], KindOut, P.index(I)))
|
2018-10-17 15:33:42 +08:00
|
|
|
Out.set(size_t(KindOut));
|
2018-09-28 01:13:07 +08:00
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const CompletionItem &CI) {
|
2017-04-04 17:46:39 +08:00
|
|
|
assert(!CI.label.empty() && "completion item label is required");
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Object Result{{"label", CI.label}};
|
2017-04-04 17:46:39 +08:00
|
|
|
if (CI.kind != CompletionItemKind::Missing)
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
Result["kind"] = static_cast<int>(CI.kind);
|
2017-04-04 17:46:39 +08:00
|
|
|
if (!CI.detail.empty())
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
Result["detail"] = CI.detail;
|
2020-04-30 16:49:32 +08:00
|
|
|
if (CI.documentation)
|
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())
|
2019-01-07 23:45:19 +08:00
|
|
|
Result["additionalTextEdits"] = llvm::json::Array(CI.additionalTextEdits);
|
2018-09-07 02:52:26 +08:00
|
|
|
if (CI.deprecated)
|
|
|
|
Result["deprecated"] = CI.deprecated;
|
2020-02-13 21:17:30 +08:00
|
|
|
Result["score"] = CI.score;
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
return std::move(Result);
|
2017-04-04 17:46:39 +08:00
|
|
|
}
|
2017-10-06 19:54:17 +08:00
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &O, const CompletionItem &I) {
|
[clangd] Use operator<< to prevent printers issues in Gtest
Summary:
It is possible that there will be two different instantiations of
the printer template for a given type and some tests could end up calling the
wrong (default) one. For example, it was seen in CodeCompleteTests.cpp when
printing CompletionItems that it would use the wrong printer because the default
is also instantiated in ClangdTests.cpp.
With this change, objects that were previously printed with a custom Printer now
get printed through the operator<< which is declared alongside the class.
This rule of the thumb should make it less error-prone.
Reviewers: simark, ilya-biryukov, sammccall
Reviewed By: simark, ilya-biryukov, sammccall
Subscribers: bkramer, hokein, sammccall, klimek, ilya-biryukov, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44764
llvm-svn: 329725
2018-04-11 01:34:46 +08:00
|
|
|
O << I.label << " - " << toJSON(I);
|
|
|
|
return O;
|
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
bool operator<(const CompletionItem &L, const CompletionItem &R) {
|
2017-11-08 15:44:12 +08:00
|
|
|
return (L.sortText.empty() ? L.label : L.sortText) <
|
|
|
|
(R.sortText.empty() ? R.label : R.sortText);
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const CompletionList &L) {
|
|
|
|
return llvm::json::Object{
|
2017-11-15 17:16:29 +08:00
|
|
|
{"isIncomplete", L.isIncomplete},
|
2019-01-07 23:45:19 +08:00
|
|
|
{"items", llvm::json::Array(L.items)},
|
2017-11-15 17:16:29 +08:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const ParameterInformation &PI) {
|
2019-06-04 19:31:45 +08:00
|
|
|
assert((PI.labelOffsets.hasValue() || !PI.labelString.empty()) &&
|
|
|
|
"parameter information label is required");
|
2019-06-04 17:36:59 +08:00
|
|
|
llvm::json::Object Result;
|
|
|
|
if (PI.labelOffsets)
|
|
|
|
Result["label"] =
|
|
|
|
llvm::json::Array({PI.labelOffsets->first, PI.labelOffsets->second});
|
|
|
|
else
|
|
|
|
Result["label"] = PI.labelString;
|
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
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const SignatureInformation &SI) {
|
2017-10-06 19:54:17 +08:00
|
|
|
assert(!SI.label.empty() && "signature information label is required");
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Object Result{
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
{"label", SI.label},
|
2019-01-07 23:45:19 +08:00
|
|
|
{"parameters", llvm::json::Array(SI.parameters)},
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
};
|
2017-10-06 19:54:17 +08:00
|
|
|
if (!SI.documentation.empty())
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
Result["documentation"] = SI.documentation;
|
|
|
|
return std::move(Result);
|
2017-10-06 19:54:17 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &O,
|
|
|
|
const SignatureInformation &I) {
|
[clangd] Use operator<< to prevent printers issues in Gtest
Summary:
It is possible that there will be two different instantiations of
the printer template for a given type and some tests could end up calling the
wrong (default) one. For example, it was seen in CodeCompleteTests.cpp when
printing CompletionItems that it would use the wrong printer because the default
is also instantiated in ClangdTests.cpp.
With this change, objects that were previously printed with a custom Printer now
get printed through the operator<< which is declared alongside the class.
This rule of the thumb should make it less error-prone.
Reviewers: simark, ilya-biryukov, sammccall
Reviewed By: simark, ilya-biryukov, sammccall
Subscribers: bkramer, hokein, sammccall, klimek, ilya-biryukov, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44764
llvm-svn: 329725
2018-04-11 01:34:46 +08:00
|
|
|
O << I.label << " - " << toJSON(I);
|
|
|
|
return O;
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const SignatureHelp &SH) {
|
2017-10-06 19:54:17 +08:00
|
|
|
assert(SH.activeSignature >= 0 &&
|
|
|
|
"Unexpected negative value for number of active signatures.");
|
|
|
|
assert(SH.activeParameter >= 0 &&
|
|
|
|
"Unexpected negative value for active parameter index");
|
2019-01-07 23:45:19 +08:00
|
|
|
return llvm::json::Object{
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
{"activeSignature", SH.activeSignature},
|
|
|
|
{"activeParameter", SH.activeParameter},
|
2019-01-07 23:45:19 +08:00
|
|
|
{"signatures", llvm::json::Array(SH.signatures)},
|
Adds a json::Expr type to represent intermediate JSON expressions.
Summary:
This form can be created with a nice clang-format-friendly literal syntax,
and gets escaping right. It knows how to call unparse() on our Protocol types.
All the places where we pass around JSON internally now use this type.
Object properties are sorted (stored as std::map) and so serialization is
canonicalized, with optional prettyprinting (triggered by a -pretty flag).
This makes the lit tests much nicer to read and somewhat nicer to debug.
(Unfortunately the completion tests use CHECK-DAG, which only has
line-granularity, so pretty-printing is disabled there. In future we
could make completion ordering deterministic, or switch to unittests).
Compared to the current approach, it has some efficiencies like avoiding copies
of string literals used as object keys, but is probably slower overall.
I think the code/test quality benefits are worth it.
This patch doesn't attempt to do anything about JSON *parsing*.
It takes direction from the proposal in this doc[1], but is limited in scope
and visibility, for now.
I am of half a mind just to use Expr as the target of a parser, and maybe do a
little string deduplication, but not bother with clever memory allocation.
That would be simple, and fast enough for clangd...
[1] https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cVS1uGHRyGTXaoy3DjqM4/edit
+cc d0k so he can tell me not to use std::map.
Reviewers: ioeric, malaperle
Subscribers: bkramer, ilya-biryukov, mgorny, klimek
Differential Revision: https://reviews.llvm.org/D39435
llvm-svn: 317486
2017-11-06 23:40:30 +08:00
|
|
|
};
|
2017-10-06 19:54:17 +08:00
|
|
|
}
|
2017-11-09 19:30:04 +08:00
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, RenameParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2017-12-01 05:32:29 +08:00
|
|
|
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
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::json::Value toJSON(const DocumentHighlight &DH) {
|
|
|
|
return llvm::json::Object{
|
[clangd] Document highlights for clangd
Summary: Implementation of Document Highlights Request as described in
LSP.
Contributed by William Enright (nebiroth).
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Reviewed By: malaperle
Subscribers: mgrang, sammccall, klimek, ioeric, rwols, cfe-commits, arphaman, ilya-biryukov
Differential Revision: https://reviews.llvm.org/D38425
llvm-svn: 320474
2017-12-12 20:27:47 +08:00
|
|
|
{"range", toJSON(DH.range)},
|
|
|
|
{"kind", static_cast<int>(DH.kind)},
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2018-12-20 23:39:12 +08:00
|
|
|
llvm::json::Value toJSON(const FileStatus &FStatus) {
|
2019-01-07 23:45:19 +08:00
|
|
|
return llvm::json::Object{
|
2019-01-03 21:28:05 +08:00
|
|
|
{"uri", FStatus.uri},
|
|
|
|
{"state", FStatus.state},
|
2018-12-20 23:39:12 +08:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
[clangd] Support textDocument/semanticTokens/edits
Summary:
This returns incremental highlights as a set of edits against the
previous highlights.
Server-side, we compute the full set of highlights, this just saves
wire-format size.
For now, the diff used is trivial: everything from the first change to
the last change is sent as a single edit.
The wire format is grungy - the replacement offset/length refer to
positions in the encoded array instead of the logical list of tokens.
We use token-oriented structs and translating to LSP forms when serializing.
This departs from LSP (but is consistent with semanticTokens today).
Tested in VSCode insiders (with a patched client to enable experimental
features).
Reviewers: hokein
Subscribers: ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77225
2020-04-01 22:21:44 +08:00
|
|
|
constexpr unsigned SemanticTokenEncodingSize = 5;
|
|
|
|
static llvm::json::Value encodeTokens(llvm::ArrayRef<SemanticToken> Toks) {
|
|
|
|
llvm::json::Array Result;
|
|
|
|
for (const auto &Tok : Toks) {
|
|
|
|
Result.push_back(Tok.deltaLine);
|
|
|
|
Result.push_back(Tok.deltaStart);
|
|
|
|
Result.push_back(Tok.length);
|
|
|
|
Result.push_back(Tok.tokenType);
|
|
|
|
Result.push_back(Tok.tokenModifiers);
|
|
|
|
}
|
|
|
|
assert(Result.size() == SemanticTokenEncodingSize * Toks.size());
|
2020-04-20 21:16:11 +08:00
|
|
|
return std::move(Result);
|
[clangd] Support textDocument/semanticTokens/edits
Summary:
This returns incremental highlights as a set of edits against the
previous highlights.
Server-side, we compute the full set of highlights, this just saves
wire-format size.
For now, the diff used is trivial: everything from the first change to
the last change is sent as a single edit.
The wire format is grungy - the replacement offset/length refer to
positions in the encoded array instead of the logical list of tokens.
We use token-oriented structs and translating to LSP forms when serializing.
This departs from LSP (but is consistent with semanticTokens today).
Tested in VSCode insiders (with a patched client to enable experimental
features).
Reviewers: hokein
Subscribers: ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77225
2020-04-01 22:21:44 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool operator==(const SemanticToken &L, const SemanticToken &R) {
|
|
|
|
return std::tie(L.deltaLine, L.deltaStart, L.length, L.tokenType,
|
|
|
|
L.tokenModifiers) == std::tie(R.deltaLine, R.deltaStart,
|
|
|
|
R.length, R.tokenType,
|
|
|
|
R.tokenModifiers);
|
2020-03-24 09:24:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::json::Value toJSON(const SemanticTokens &Tokens) {
|
[clangd] Support textDocument/semanticTokens/edits
Summary:
This returns incremental highlights as a set of edits against the
previous highlights.
Server-side, we compute the full set of highlights, this just saves
wire-format size.
For now, the diff used is trivial: everything from the first change to
the last change is sent as a single edit.
The wire format is grungy - the replacement offset/length refer to
positions in the encoded array instead of the logical list of tokens.
We use token-oriented structs and translating to LSP forms when serializing.
This departs from LSP (but is consistent with semanticTokens today).
Tested in VSCode insiders (with a patched client to enable experimental
features).
Reviewers: hokein
Subscribers: ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77225
2020-04-01 22:21:44 +08:00
|
|
|
return llvm::json::Object{{"resultId", Tokens.resultId},
|
|
|
|
{"data", encodeTokens(Tokens.tokens)}};
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::json::Value toJSON(const SemanticTokensEdit &Edit) {
|
|
|
|
return llvm::json::Object{
|
|
|
|
{"start", SemanticTokenEncodingSize * Edit.startToken},
|
|
|
|
{"deleteCount", SemanticTokenEncodingSize * Edit.deleteTokens},
|
|
|
|
{"data", encodeTokens(Edit.tokens)}};
|
|
|
|
}
|
|
|
|
|
2020-07-10 22:08:14 +08:00
|
|
|
llvm::json::Value toJSON(const SemanticTokensOrDelta &TE) {
|
[clangd] Support textDocument/semanticTokens/edits
Summary:
This returns incremental highlights as a set of edits against the
previous highlights.
Server-side, we compute the full set of highlights, this just saves
wire-format size.
For now, the diff used is trivial: everything from the first change to
the last change is sent as a single edit.
The wire format is grungy - the replacement offset/length refer to
positions in the encoded array instead of the logical list of tokens.
We use token-oriented structs and translating to LSP forms when serializing.
This departs from LSP (but is consistent with semanticTokens today).
Tested in VSCode insiders (with a patched client to enable experimental
features).
Reviewers: hokein
Subscribers: ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77225
2020-04-01 22:21:44 +08:00
|
|
|
llvm::json::Object Result{{"resultId", TE.resultId}};
|
|
|
|
if (TE.edits)
|
|
|
|
Result["edits"] = *TE.edits;
|
|
|
|
if (TE.tokens)
|
|
|
|
Result["data"] = encodeTokens(*TE.tokens);
|
2020-04-20 21:16:11 +08:00
|
|
|
return std::move(Result);
|
2020-03-24 09:24:47 +08:00
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, SemanticTokensParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2020-03-24 09:24:47 +08:00
|
|
|
return O && O.map("textDocument", R.textDocument);
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, SemanticTokensDeltaParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
[clangd] Support textDocument/semanticTokens/edits
Summary:
This returns incremental highlights as a set of edits against the
previous highlights.
Server-side, we compute the full set of highlights, this just saves
wire-format size.
For now, the diff used is trivial: everything from the first change to
the last change is sent as a single edit.
The wire format is grungy - the replacement offset/length refer to
positions in the encoded array instead of the logical list of tokens.
We use token-oriented structs and translating to LSP forms when serializing.
This departs from LSP (but is consistent with semanticTokens today).
Tested in VSCode insiders (with a patched client to enable experimental
features).
Reviewers: hokein
Subscribers: ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77225
2020-04-01 22:21:44 +08:00
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("previousResultId", R.previousResultId);
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &O,
|
|
|
|
const DocumentHighlight &V) {
|
[clangd] Use operator<< to prevent printers issues in Gtest
Summary:
It is possible that there will be two different instantiations of
the printer template for a given type and some tests could end up calling the
wrong (default) one. For example, it was seen in CodeCompleteTests.cpp when
printing CompletionItems that it would use the wrong printer because the default
is also instantiated in ClangdTests.cpp.
With this change, objects that were previously printed with a custom Printer now
get printed through the operator<< which is declared alongside the class.
This rule of the thumb should make it less error-prone.
Reviewers: simark, ilya-biryukov, sammccall
Reviewed By: simark, ilya-biryukov, sammccall
Subscribers: bkramer, hokein, sammccall, klimek, ilya-biryukov, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44764
llvm-svn: 329725
2018-04-11 01:34:46 +08:00
|
|
|
O << V.range;
|
|
|
|
if (V.kind == DocumentHighlightKind::Read)
|
|
|
|
O << "(r)";
|
|
|
|
if (V.kind == DocumentHighlightKind::Write)
|
|
|
|
O << "(w)";
|
|
|
|
return O;
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params,
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
DidChangeConfigurationParams &CCP, llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
[clangd] DidChangeConfiguration Notification
Summary:
Implementation of DidChangeConfiguration notification handling in
clangd. This currently only supports changing one setting: the path of
the compilation database to be used for the current project. In other
words, it is no longer necessary to restart clangd with a different
command line argument in order to change the compilation database.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: jkorous-apple, ioeric, simark, klimek, ilya-biryukov, arphaman, rwols, cfe-commits
Differential Revision: https://reviews.llvm.org/D39571
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325784
2018-02-22 22:00:39 +08:00
|
|
|
return O && O.map("settings", CCP.settings);
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, ClangdCompileCommand &CDbUpdate,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2018-08-02 01:39:29 +08:00
|
|
|
return O && O.map("workingDirectory", CDbUpdate.workingDirectory) &&
|
|
|
|
O.map("compilationCommand", CDbUpdate.compilationCommand);
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, ConfigurationSettings &S,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2018-10-25 12:22:52 +08:00
|
|
|
if (!O)
|
|
|
|
return true; // 'any' type in LSP.
|
2021-01-22 22:20:52 +08:00
|
|
|
return mapOptOrNull(Params, "compilationDatabaseChanges",
|
|
|
|
S.compilationDatabaseChanges, P);
|
[clangd] DidChangeConfiguration Notification
Summary:
Implementation of DidChangeConfiguration notification handling in
clangd. This currently only supports changing one setting: the path of
the compilation database to be used for the current project. In other
words, it is no longer necessary to restart clangd with a different
command line argument in order to change the compilation database.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: jkorous-apple, ioeric, simark, klimek, ilya-biryukov, arphaman, rwols, cfe-commits
Differential Revision: https://reviews.llvm.org/D39571
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325784
2018-02-22 22:00:39 +08:00
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, InitializationOptions &Opts,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2018-10-25 12:22:52 +08:00
|
|
|
if (!O)
|
|
|
|
return true; // 'any' type in LSP.
|
|
|
|
|
2020-10-09 22:06:46 +08:00
|
|
|
return fromJSON(Params, Opts.ConfigSettings, P) &&
|
|
|
|
O.map("compilationDatabasePath", Opts.compilationDatabasePath) &&
|
2021-01-22 22:20:52 +08:00
|
|
|
mapOptOrNull(Params, "fallbackFlags", Opts.fallbackFlags, P) &&
|
|
|
|
mapOptOrNull(Params, "clangdFileStatus", Opts.FileStatus, P);
|
2018-10-16 23:55:03 +08:00
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &E, TypeHierarchyDirection &Out,
|
|
|
|
llvm::json::Path P) {
|
[clangd] Add support for type hierarchy (super types only for now)
Summary:
Patch by Nathan Ridge(@nridge)!
This is an LSP extension proposed here:
https://github.com/Microsoft/vscode-languageserver-node/pull/426
An example client implementation can be found here:
https://github.com/theia-ide/theia/pull/3802
Reviewers: kadircet, sammccall
Reviewed By: kadircet
Subscribers: jdoerfert, sammccall, cfe-commits, mgorny, dschaefer, simark, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet
Tags: #clang
Differential Revision: https://reviews.llvm.org/D56370
llvm-svn: 356445
2019-03-19 17:27:04 +08:00
|
|
|
auto T = E.getAsInteger();
|
|
|
|
if (!T)
|
|
|
|
return false;
|
|
|
|
if (*T < static_cast<int>(TypeHierarchyDirection::Children) ||
|
|
|
|
*T > static_cast<int>(TypeHierarchyDirection::Both))
|
|
|
|
return false;
|
|
|
|
Out = static_cast<TypeHierarchyDirection>(*T);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, TypeHierarchyParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
[clangd] Add support for type hierarchy (super types only for now)
Summary:
Patch by Nathan Ridge(@nridge)!
This is an LSP extension proposed here:
https://github.com/Microsoft/vscode-languageserver-node/pull/426
An example client implementation can be found here:
https://github.com/theia-ide/theia/pull/3802
Reviewers: kadircet, sammccall
Reviewed By: kadircet
Subscribers: jdoerfert, sammccall, cfe-commits, mgorny, dschaefer, simark, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet
Tags: #clang
Differential Revision: https://reviews.llvm.org/D56370
llvm-svn: 356445
2019-03-19 17:27:04 +08:00
|
|
|
return O && O.map("textDocument", R.textDocument) &&
|
|
|
|
O.map("position", R.position) && O.map("resolve", R.resolve) &&
|
|
|
|
O.map("direction", R.direction);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &O,
|
|
|
|
const TypeHierarchyItem &I) {
|
|
|
|
return O << I.name << " - " << toJSON(I);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::json::Value toJSON(const TypeHierarchyItem &I) {
|
|
|
|
llvm::json::Object Result{{"name", I.name},
|
|
|
|
{"kind", static_cast<int>(I.kind)},
|
|
|
|
{"range", I.range},
|
|
|
|
{"selectionRange", I.selectionRange},
|
|
|
|
{"uri", I.uri}};
|
|
|
|
|
|
|
|
if (I.detail)
|
|
|
|
Result["detail"] = I.detail;
|
|
|
|
if (I.deprecated)
|
|
|
|
Result["deprecated"] = I.deprecated;
|
|
|
|
if (I.parents)
|
|
|
|
Result["parents"] = I.parents;
|
|
|
|
if (I.children)
|
|
|
|
Result["children"] = I.children;
|
2019-07-13 11:24:48 +08:00
|
|
|
if (I.data)
|
|
|
|
Result["data"] = I.data;
|
[clangd] Add support for type hierarchy (super types only for now)
Summary:
Patch by Nathan Ridge(@nridge)!
This is an LSP extension proposed here:
https://github.com/Microsoft/vscode-languageserver-node/pull/426
An example client implementation can be found here:
https://github.com/theia-ide/theia/pull/3802
Reviewers: kadircet, sammccall
Reviewed By: kadircet
Subscribers: jdoerfert, sammccall, cfe-commits, mgorny, dschaefer, simark, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet
Tags: #clang
Differential Revision: https://reviews.llvm.org/D56370
llvm-svn: 356445
2019-03-19 17:27:04 +08:00
|
|
|
return std::move(Result);
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, TypeHierarchyItem &I,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
[clangd] Add support for type hierarchy (super types only for now)
Summary:
Patch by Nathan Ridge(@nridge)!
This is an LSP extension proposed here:
https://github.com/Microsoft/vscode-languageserver-node/pull/426
An example client implementation can be found here:
https://github.com/theia-ide/theia/pull/3802
Reviewers: kadircet, sammccall
Reviewed By: kadircet
Subscribers: jdoerfert, sammccall, cfe-commits, mgorny, dschaefer, simark, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet
Tags: #clang
Differential Revision: https://reviews.llvm.org/D56370
llvm-svn: 356445
2019-03-19 17:27:04 +08:00
|
|
|
|
|
|
|
// Required fields.
|
2020-10-09 22:06:46 +08:00
|
|
|
return O && O.map("name", I.name) && O.map("kind", I.kind) &&
|
|
|
|
O.map("uri", I.uri) && O.map("range", I.range) &&
|
|
|
|
O.map("selectionRange", I.selectionRange) &&
|
2021-01-22 22:20:52 +08:00
|
|
|
mapOptOrNull(Params, "detail", I.detail, P) &&
|
|
|
|
mapOptOrNull(Params, "deprecated", I.deprecated, P) &&
|
|
|
|
mapOptOrNull(Params, "parents", I.parents, P) &&
|
|
|
|
mapOptOrNull(Params, "children", I.children, P) &&
|
|
|
|
mapOptOrNull(Params, "data", I.data, P);
|
[clangd] Add support for type hierarchy (super types only for now)
Summary:
Patch by Nathan Ridge(@nridge)!
This is an LSP extension proposed here:
https://github.com/Microsoft/vscode-languageserver-node/pull/426
An example client implementation can be found here:
https://github.com/theia-ide/theia/pull/3802
Reviewers: kadircet, sammccall
Reviewed By: kadircet
Subscribers: jdoerfert, sammccall, cfe-commits, mgorny, dschaefer, simark, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet
Tags: #clang
Differential Revision: https://reviews.llvm.org/D56370
llvm-svn: 356445
2019-03-19 17:27:04 +08:00
|
|
|
}
|
|
|
|
|
2019-07-13 11:24:48 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params,
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
ResolveTypeHierarchyItemParams &R, llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
|
|
|
return O && O.map("item", R.item) && O.map("resolve", R.resolve) &&
|
|
|
|
O.map("direction", R.direction);
|
2019-07-13 11:24:48 +08:00
|
|
|
}
|
|
|
|
|
2021-01-27 00:16:57 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, ReferenceContext &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
|
|
|
return O && O.mapOptional("includeDeclaration", R.includeDeclaration);
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, ReferenceParams &R,
|
|
|
|
llvm::json::Path P) {
|
2018-09-05 19:53:07 +08:00
|
|
|
TextDocumentPositionParams &Base = R;
|
2021-01-27 00:16:57 +08:00
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
|
|
|
return fromJSON(Params, Base, P) && O && O.mapOptional("context", R.context);
|
2018-09-05 19:53:07 +08:00
|
|
|
}
|
|
|
|
|
2020-11-10 13:20:38 +08:00
|
|
|
llvm::json::Value toJSON(SymbolTag Tag) {
|
|
|
|
return llvm::json::Value{static_cast<int>(Tag)};
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::json::Value toJSON(const CallHierarchyItem &I) {
|
|
|
|
llvm::json::Object Result{{"name", I.name},
|
|
|
|
{"kind", static_cast<int>(I.kind)},
|
|
|
|
{"range", I.range},
|
|
|
|
{"selectionRange", I.selectionRange},
|
|
|
|
{"uri", I.uri}};
|
|
|
|
if (!I.tags.empty())
|
|
|
|
Result["tags"] = I.tags;
|
|
|
|
if (!I.detail.empty())
|
|
|
|
Result["detail"] = I.detail;
|
|
|
|
if (!I.data.empty())
|
|
|
|
Result["data"] = I.data;
|
|
|
|
return std::move(Result);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const llvm::json::Value &Params, CallHierarchyItem &I,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
|
|
|
|
|
|
|
// Populate the required fields only. We don't care about the
|
|
|
|
// optional fields `Tags` and `Detail` for the purpose of
|
|
|
|
// client --> server communication.
|
|
|
|
return O && O.map("name", I.name) && O.map("kind", I.kind) &&
|
|
|
|
O.map("uri", I.uri) && O.map("range", I.range) &&
|
|
|
|
O.map("selectionRange", I.selectionRange) &&
|
2021-01-22 22:20:52 +08:00
|
|
|
mapOptOrNull(Params, "data", I.data, P);
|
2020-11-10 13:20:38 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const llvm::json::Value &Params,
|
|
|
|
CallHierarchyIncomingCallsParams &C, llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
|
|
|
return O.map("item", C.item);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::json::Value toJSON(const CallHierarchyIncomingCall &C) {
|
|
|
|
return llvm::json::Object{{"from", C.from}, {"fromRanges", C.fromRanges}};
|
|
|
|
}
|
|
|
|
|
|
|
|
bool fromJSON(const llvm::json::Value &Params,
|
|
|
|
CallHierarchyOutgoingCallsParams &C, llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
|
|
|
return O.map("item", C.item);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::json::Value toJSON(const CallHierarchyOutgoingCall &C) {
|
|
|
|
return llvm::json::Object{{"to", C.to}, {"fromRanges", C.fromRanges}};
|
|
|
|
}
|
|
|
|
|
2019-03-28 22:37:51 +08:00
|
|
|
static const char *toString(OffsetEncoding OE) {
|
2019-03-28 01:47:49 +08:00
|
|
|
switch (OE) {
|
2019-03-28 22:37:51 +08:00
|
|
|
case OffsetEncoding::UTF8:
|
|
|
|
return "utf-8";
|
|
|
|
case OffsetEncoding::UTF16:
|
|
|
|
return "utf-16";
|
|
|
|
case OffsetEncoding::UTF32:
|
|
|
|
return "utf-32";
|
|
|
|
case OffsetEncoding::UnsupportedEncoding:
|
|
|
|
return "unknown";
|
2019-03-28 01:47:49 +08:00
|
|
|
}
|
2019-03-29 21:43:00 +08:00
|
|
|
llvm_unreachable("Unknown clang.clangd.OffsetEncoding");
|
2019-03-28 01:47:49 +08:00
|
|
|
}
|
2019-03-28 22:37:51 +08:00
|
|
|
llvm::json::Value toJSON(const OffsetEncoding &OE) { return toString(OE); }
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &V, OffsetEncoding &OE,
|
|
|
|
llvm::json::Path P) {
|
2019-03-28 01:47:49 +08:00
|
|
|
auto Str = V.getAsString();
|
|
|
|
if (!Str)
|
|
|
|
return false;
|
|
|
|
OE = llvm::StringSwitch<OffsetEncoding>(*Str)
|
|
|
|
.Case("utf-8", OffsetEncoding::UTF8)
|
|
|
|
.Case("utf-16", OffsetEncoding::UTF16)
|
2019-03-28 22:37:51 +08:00
|
|
|
.Case("utf-32", OffsetEncoding::UTF32)
|
2019-03-28 01:47:49 +08:00
|
|
|
.Default(OffsetEncoding::UnsupportedEncoding);
|
|
|
|
return true;
|
|
|
|
}
|
2019-03-28 22:37:51 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, OffsetEncoding Enc) {
|
|
|
|
return OS << toString(Enc);
|
|
|
|
}
|
2019-03-28 01:47:49 +08:00
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, SelectionRangeParams &S,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
|
|
|
return O && O.map("textDocument", S.textDocument) &&
|
|
|
|
O.map("positions", S.positions);
|
2019-09-24 21:38:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
llvm::json::Value toJSON(const SelectionRange &Out) {
|
|
|
|
if (Out.parent) {
|
|
|
|
return llvm::json::Object{{"range", Out.range},
|
|
|
|
{"parent", toJSON(*Out.parent)}};
|
|
|
|
}
|
|
|
|
return llvm::json::Object{{"range", Out.range}};
|
|
|
|
}
|
2019-12-17 02:08:51 +08:00
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, DocumentLinkParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
2019-12-17 02:08:51 +08:00
|
|
|
return O && O.map("textDocument", R.textDocument);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::json::Value toJSON(const DocumentLink &DocumentLink) {
|
|
|
|
return llvm::json::Object{
|
|
|
|
{"range", DocumentLink.range},
|
|
|
|
{"target", DocumentLink.target},
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
[JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 07:14:12 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Params, FoldingRangeParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
[clangd] Implement textDocument/foldingRange
Summary:
This patch introduces basic textDocument/foldingRange support. It relies on
textDocument/documentSymbols to collect all symbols and uses takes ranges
to create folds.
The next steps for textDocument/foldingRange support would be:
* Implementing FoldingRangeClientCapabilities and respecting respect client
preferences
* Specifying folding range kind
* Migrating from DocumentSymbol implementation to custom RecursiveASTVisitor flow that will allow more flexibility
* Supporting more folding range types: comments, PP conditional regions, includes and other code regions (e.g. public/private/protected sections of classes, control flow statement bodies)
Tested: (Neo)Vim (coc-clangd) and VSCode.
Related issue: https://github.com/clangd/clangd/issues/310
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: nridge, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D82436
2020-07-14 15:28:38 +08:00
|
|
|
return O && O.map("textDocument", R.textDocument);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::json::Value toJSON(const FoldingRange &Range) {
|
|
|
|
llvm::json::Object Result{
|
|
|
|
{"startLine", Range.startLine},
|
|
|
|
{"endLine", Range.endLine},
|
|
|
|
};
|
|
|
|
if (Range.startCharacter)
|
|
|
|
Result["startCharacter"] = Range.startCharacter;
|
|
|
|
if (Range.endCharacter)
|
|
|
|
Result["endCharacter"] = Range.endCharacter;
|
|
|
|
if (Range.kind)
|
|
|
|
Result["kind"] = *Range.kind;
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2020-10-13 06:10:04 +08:00
|
|
|
llvm::json::Value toJSON(const MemoryTree &MT) {
|
|
|
|
llvm::json::Object Out;
|
|
|
|
int64_t Total = MT.self();
|
|
|
|
Out["_self"] = Total;
|
|
|
|
for (const auto &Entry : MT.children()) {
|
|
|
|
auto Child = toJSON(Entry.getSecond());
|
|
|
|
Total += *Child.getAsObject()->getInteger("_total");
|
|
|
|
Out[Entry.first] = std::move(Child);
|
|
|
|
}
|
|
|
|
Out["_total"] = Total;
|
|
|
|
return Out;
|
|
|
|
}
|
2020-10-17 02:03:48 +08:00
|
|
|
|
|
|
|
bool fromJSON(const llvm::json::Value &Params, ASTParams &R,
|
|
|
|
llvm::json::Path P) {
|
|
|
|
llvm::json::ObjectMapper O(Params, P);
|
|
|
|
return O && O.map("textDocument", R.textDocument) && O.map("range", R.range);
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::json::Value toJSON(const ASTNode &N) {
|
|
|
|
llvm::json::Object Result{
|
|
|
|
{"role", N.role},
|
|
|
|
{"kind", N.kind},
|
|
|
|
};
|
|
|
|
if (!N.children.empty())
|
|
|
|
Result["children"] = N.children;
|
|
|
|
if (!N.detail.empty())
|
|
|
|
Result["detail"] = N.detail;
|
|
|
|
if (!N.arcana.empty())
|
|
|
|
Result["arcana"] = N.arcana;
|
|
|
|
if (N.range)
|
|
|
|
Result["range"] = *N.range;
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const ASTNode &Root) {
|
|
|
|
std::function<void(const ASTNode &, unsigned)> Print = [&](const ASTNode &N,
|
|
|
|
unsigned Level) {
|
|
|
|
OS.indent(2 * Level) << N.role << ": " << N.kind;
|
|
|
|
if (!N.detail.empty())
|
|
|
|
OS << " - " << N.detail;
|
|
|
|
OS << "\n";
|
|
|
|
for (const ASTNode &C : N.children)
|
|
|
|
Print(C, Level + 1);
|
|
|
|
};
|
|
|
|
Print(Root, 0);
|
|
|
|
return OS;
|
|
|
|
}
|
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
} // namespace clangd
|
|
|
|
} // namespace clang
|