2017-02-07 18:28:20 +08:00
|
|
|
//===--- Protocol.h - Language Server Protocol Implementation ---*- C++ -*-===//
|
|
|
|
//
|
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 structs based on the LSP specification at
|
|
|
|
// https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md
|
|
|
|
//
|
|
|
|
// This is not meant to be a complete implementation, new interfaces are added
|
|
|
|
// when they're needed.
|
|
|
|
//
|
2017-12-01 05:32:29 +08:00
|
|
|
// Each struct has a toJSON and fromJSON function, that converts between
|
2018-07-09 22:25:59 +08:00
|
|
|
// the struct and a JSON representation. (See JSON.h)
|
2017-02-07 18:28:20 +08:00
|
|
|
//
|
2017-12-20 18:26:53 +08:00
|
|
|
// Some structs also have operator<< serialization. This is for debugging and
|
|
|
|
// tests, and is not generally machine-readable.
|
|
|
|
//
|
2017-02-07 18:28:20 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_PROTOCOL_H
|
|
|
|
#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_PROTOCOL_H
|
|
|
|
|
2018-01-29 23:37:46 +08:00
|
|
|
#include "URI.h"
|
2018-11-28 00:40:34 +08:00
|
|
|
#include "index/SymbolID.h"
|
2020-10-13 06:10:04 +08:00
|
|
|
#include "support/MemoryTree.h"
|
[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
|
|
|
#include "clang/Index/IndexSymbol.h"
|
2017-02-07 18:28:20 +08:00
|
|
|
#include "llvm/ADT/Optional.h"
|
2018-07-09 22:25:59 +08:00
|
|
|
#include "llvm/Support/JSON.h"
|
2019-03-28 22:37:51 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
[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
|
|
|
#include <bitset>
|
2019-09-24 21:38:33 +08:00
|
|
|
#include <memory>
|
2017-02-07 18:28:20 +08:00
|
|
|
#include <string>
|
2017-02-07 18:47:40 +08:00
|
|
|
#include <vector>
|
2017-02-07 18:28:20 +08:00
|
|
|
|
|
|
|
namespace clang {
|
|
|
|
namespace clangd {
|
|
|
|
|
2017-11-07 18:21:02 +08:00
|
|
|
enum class ErrorCode {
|
|
|
|
// Defined by JSON RPC.
|
|
|
|
ParseError = -32700,
|
|
|
|
InvalidRequest = -32600,
|
|
|
|
MethodNotFound = -32601,
|
|
|
|
InvalidParams = -32602,
|
|
|
|
InternalError = -32603,
|
|
|
|
|
|
|
|
ServerNotInitialized = -32002,
|
|
|
|
UnknownErrorCode = -32001,
|
|
|
|
|
|
|
|
// Defined by the protocol.
|
|
|
|
RequestCancelled = -32800,
|
2020-04-12 00:19:50 +08:00
|
|
|
ContentModified = -32801,
|
2017-11-07 18:21:02 +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
|
|
|
// Models an LSP error as an llvm::Error.
|
|
|
|
class LSPError : public llvm::ErrorInfo<LSPError> {
|
|
|
|
public:
|
|
|
|
std::string Message;
|
|
|
|
ErrorCode Code;
|
|
|
|
static char ID;
|
|
|
|
|
|
|
|
LSPError(std::string Message, ErrorCode Code)
|
|
|
|
: Message(std::move(Message)), Code(Code) {}
|
|
|
|
|
|
|
|
void log(llvm::raw_ostream &OS) const override {
|
|
|
|
OS << int(Code) << ": " << Message;
|
|
|
|
}
|
|
|
|
std::error_code convertToErrorCode() const override {
|
|
|
|
return llvm::inconvertibleErrorCode();
|
|
|
|
}
|
|
|
|
};
|
2017-11-07 18:21:02 +08:00
|
|
|
|
2018-11-28 18:30:42 +08:00
|
|
|
// URI in "file" scheme for a file.
|
2018-01-29 23:37:46 +08:00
|
|
|
struct URIForFile {
|
2018-02-16 20:20:47 +08:00
|
|
|
URIForFile() = default;
|
2018-11-28 18:30:42 +08:00
|
|
|
|
|
|
|
/// Canonicalizes \p AbsPath via URI.
|
|
|
|
///
|
|
|
|
/// File paths in URIForFile can come from index or local AST. Path from
|
|
|
|
/// index goes through URI transformation, and the final path is resolved by
|
|
|
|
/// URI scheme and could potentially be different from the original path.
|
|
|
|
/// Hence, we do the same transformation for all paths.
|
|
|
|
///
|
|
|
|
/// Files can be referred to by several paths (e.g. in the presence of links).
|
|
|
|
/// Which one we prefer may depend on where we're coming from. \p TUPath is a
|
|
|
|
/// hint, and should usually be the main entrypoint file we're processing.
|
|
|
|
static URIForFile canonicalize(llvm::StringRef AbsPath,
|
|
|
|
llvm::StringRef TUPath);
|
|
|
|
|
|
|
|
static llvm::Expected<URIForFile> fromURI(const URI &U,
|
|
|
|
llvm::StringRef HintPath);
|
2017-04-07 19:03:26 +08:00
|
|
|
|
2018-02-16 20:20:47 +08:00
|
|
|
/// Retrieves absolute path to the file.
|
|
|
|
llvm::StringRef file() const { return File; }
|
|
|
|
|
|
|
|
explicit operator bool() const { return !File.empty(); }
|
|
|
|
std::string uri() const { return URI::createFile(File).toString(); }
|
2017-04-07 19:03:26 +08:00
|
|
|
|
2018-01-29 23:37:46 +08:00
|
|
|
friend bool operator==(const URIForFile &LHS, const URIForFile &RHS) {
|
2018-02-16 20:20:47 +08:00
|
|
|
return LHS.File == RHS.File;
|
2017-06-29 00:12:10 +08:00
|
|
|
}
|
|
|
|
|
2018-01-29 23:37:46 +08:00
|
|
|
friend bool operator!=(const URIForFile &LHS, const URIForFile &RHS) {
|
2017-06-29 00:12:10 +08:00
|
|
|
return !(LHS == RHS);
|
|
|
|
}
|
|
|
|
|
2018-01-29 23:37:46 +08:00
|
|
|
friend bool operator<(const URIForFile &LHS, const URIForFile &RHS) {
|
2018-02-16 20:20:47 +08:00
|
|
|
return LHS.File < RHS.File;
|
2017-06-29 00:12:10 +08:00
|
|
|
}
|
2018-02-16 20:20:47 +08:00
|
|
|
|
|
|
|
private:
|
2018-11-28 18:30:42 +08:00
|
|
|
explicit URIForFile(std::string &&File) : File(std::move(File)) {}
|
|
|
|
|
2018-02-16 20:20:47 +08:00
|
|
|
std::string File;
|
2017-04-07 19:03:26 +08:00
|
|
|
};
|
2018-01-29 23:37:46 +08:00
|
|
|
|
|
|
|
/// Serialize/deserialize \p URIForFile to/from a string URI.
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const URIForFile &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
|
|
|
bool fromJSON(const llvm::json::Value &, URIForFile &, llvm::json::Path);
|
2017-04-07 19:03:26 +08:00
|
|
|
|
2017-02-07 18:28:20 +08:00
|
|
|
struct TextDocumentIdentifier {
|
|
|
|
/// The text document's URI.
|
2018-01-29 23:37:46 +08:00
|
|
|
URIForFile uri;
|
2017-02-07 18:28:20 +08:00
|
|
|
};
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const TextDocumentIdentifier &);
|
[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 &, TextDocumentIdentifier &,
|
|
|
|
llvm::json::Path);
|
2017-02-07 18:28:20 +08:00
|
|
|
|
2020-03-03 22:57:39 +08:00
|
|
|
struct VersionedTextDocumentIdentifier : public TextDocumentIdentifier {
|
[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
|
|
|
/// The version number of this document. If a versioned text document
|
|
|
|
/// identifier is sent from the server to the client and the file is not open
|
|
|
|
/// in the editor (the server has not received an open notification before)
|
|
|
|
/// the server can send `null` to indicate that the version is known and the
|
|
|
|
/// content on disk is the master (as speced with document content ownership).
|
|
|
|
///
|
|
|
|
/// The version number of a document will increase after each change,
|
|
|
|
/// including undo/redo. The number doesn't need to be consecutive.
|
|
|
|
///
|
|
|
|
/// clangd extension: versions are optional, and synthesized if missing.
|
2020-03-03 22:57:39 +08:00
|
|
|
llvm::Optional<std::int64_t> version;
|
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const VersionedTextDocumentIdentifier &);
|
[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 &, VersionedTextDocumentIdentifier &,
|
|
|
|
llvm::json::Path);
|
2020-03-03 22:57:39 +08:00
|
|
|
|
2017-02-07 18:28:20 +08:00
|
|
|
struct Position {
|
|
|
|
/// Line position in a document (zero-based).
|
2018-02-14 18:52:04 +08:00
|
|
|
int line = 0;
|
2017-02-07 18:28:20 +08:00
|
|
|
|
|
|
|
/// Character offset on a line in a document (zero-based).
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
/// WARNING: this is in UTF-16 codepoints, not bytes or characters!
|
|
|
|
/// Use the functions in SourceCode.h to construct/interpret Positions.
|
2018-02-14 18:52:04 +08:00
|
|
|
int character = 0;
|
2017-02-07 18:28:20 +08:00
|
|
|
|
2017-03-02 00:16:29 +08:00
|
|
|
friend bool operator==(const Position &LHS, const Position &RHS) {
|
|
|
|
return std::tie(LHS.line, LHS.character) ==
|
|
|
|
std::tie(RHS.line, RHS.character);
|
|
|
|
}
|
2018-05-15 23:29:32 +08:00
|
|
|
friend bool operator!=(const Position &LHS, const Position &RHS) {
|
|
|
|
return !(LHS == RHS);
|
|
|
|
}
|
2017-03-02 00:16:29 +08:00
|
|
|
friend bool operator<(const Position &LHS, const Position &RHS) {
|
|
|
|
return std::tie(LHS.line, LHS.character) <
|
|
|
|
std::tie(RHS.line, RHS.character);
|
|
|
|
}
|
2018-02-21 10:39:08 +08:00
|
|
|
friend bool operator<=(const Position &LHS, const Position &RHS) {
|
|
|
|
return std::tie(LHS.line, LHS.character) <=
|
|
|
|
std::tie(RHS.line, RHS.character);
|
|
|
|
}
|
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 &, Position &, llvm::json::Path);
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const Position &);
|
2017-12-20 18:26:53 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &, const Position &);
|
2017-02-07 18:28:20 +08:00
|
|
|
|
|
|
|
struct Range {
|
|
|
|
/// The range's start position.
|
|
|
|
Position start;
|
|
|
|
|
|
|
|
/// The range's end position.
|
|
|
|
Position end;
|
|
|
|
|
2017-03-02 00:16:29 +08:00
|
|
|
friend bool operator==(const Range &LHS, const Range &RHS) {
|
|
|
|
return std::tie(LHS.start, LHS.end) == std::tie(RHS.start, RHS.end);
|
|
|
|
}
|
2018-03-12 23:28:22 +08:00
|
|
|
friend bool operator!=(const Range &LHS, const Range &RHS) {
|
|
|
|
return !(LHS == RHS);
|
|
|
|
}
|
2017-03-02 00:16:29 +08:00
|
|
|
friend bool operator<(const Range &LHS, const Range &RHS) {
|
|
|
|
return std::tie(LHS.start, LHS.end) < std::tie(RHS.start, RHS.end);
|
|
|
|
}
|
2018-02-21 10:39:08 +08:00
|
|
|
|
|
|
|
bool contains(Position Pos) const { return start <= Pos && Pos < end; }
|
2018-11-23 23:21:19 +08:00
|
|
|
bool contains(Range Rng) const {
|
|
|
|
return start <= Rng.start && Rng.end <= end;
|
|
|
|
}
|
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 &, Range &, llvm::json::Path);
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const Range &);
|
2017-12-20 18:26:53 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &, const Range &);
|
2017-02-07 18:28:20 +08:00
|
|
|
|
2017-06-29 00:12:10 +08:00
|
|
|
struct Location {
|
|
|
|
/// The text document's URI.
|
2018-01-29 23:37:46 +08:00
|
|
|
URIForFile uri;
|
2017-06-29 00:12:10 +08:00
|
|
|
Range range;
|
|
|
|
|
|
|
|
friend bool operator==(const Location &LHS, const Location &RHS) {
|
|
|
|
return LHS.uri == RHS.uri && LHS.range == RHS.range;
|
|
|
|
}
|
|
|
|
|
|
|
|
friend bool operator!=(const Location &LHS, const Location &RHS) {
|
|
|
|
return !(LHS == RHS);
|
|
|
|
}
|
|
|
|
|
|
|
|
friend bool operator<(const Location &LHS, const Location &RHS) {
|
|
|
|
return std::tie(LHS.uri, LHS.range) < std::tie(RHS.uri, RHS.range);
|
|
|
|
}
|
|
|
|
};
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const Location &);
|
2017-12-20 18:26:53 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &, const Location &);
|
2017-06-29 00:12:10 +08:00
|
|
|
|
2017-02-07 18:28:20 +08:00
|
|
|
struct TextEdit {
|
|
|
|
/// The range of the text document to be manipulated. To insert
|
|
|
|
/// text into a document create a range where start === end.
|
|
|
|
Range range;
|
|
|
|
|
|
|
|
/// The string to be inserted. For delete operations use an
|
|
|
|
/// empty string.
|
|
|
|
std::string newText;
|
|
|
|
};
|
2019-05-03 16:03:21 +08:00
|
|
|
inline bool operator==(const TextEdit &L, const TextEdit &R) {
|
|
|
|
return std::tie(L.newText, L.range) == std::tie(R.newText, R.range);
|
|
|
|
}
|
[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 &, TextEdit &, llvm::json::Path);
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const TextEdit &);
|
2018-01-26 01:29:17 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &, const TextEdit &);
|
2017-02-07 18:28:20 +08:00
|
|
|
|
|
|
|
struct TextDocumentItem {
|
|
|
|
/// The text document's URI.
|
2018-01-29 23:37:46 +08:00
|
|
|
URIForFile uri;
|
2017-02-07 18:28:20 +08:00
|
|
|
|
|
|
|
/// The text document's language identifier.
|
|
|
|
std::string languageId;
|
|
|
|
|
|
|
|
/// The version number of this document (it will strictly increase after each
|
[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
|
|
|
/// change, including undo/redo.
|
|
|
|
///
|
|
|
|
/// clangd extension: versions are optional, and synthesized if missing.
|
|
|
|
llvm::Optional<int64_t> version;
|
2017-02-07 18:28:20 +08:00
|
|
|
|
|
|
|
/// The content of the opened text document.
|
|
|
|
std::string 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 &, TextDocumentItem &, llvm::json::Path);
|
2017-02-07 18:28:20 +08:00
|
|
|
|
2017-09-27 23:31:17 +08:00
|
|
|
enum class TraceLevel {
|
|
|
|
Off = 0,
|
|
|
|
Messages = 1,
|
|
|
|
Verbose = 2,
|
|
|
|
};
|
[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);
|
2017-09-27 23:31:17 +08:00
|
|
|
|
2017-12-01 05:32:29 +08:00
|
|
|
struct NoParams {};
|
[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
|
|
|
inline bool fromJSON(const llvm::json::Value &, NoParams &, llvm::json::Path) {
|
|
|
|
return true;
|
|
|
|
}
|
2020-03-03 19:12:14 +08:00
|
|
|
using InitializedParams = NoParams;
|
2017-10-12 21:29:58 +08:00
|
|
|
using ShutdownParams = NoParams;
|
2017-10-25 16:45:41 +08:00
|
|
|
using ExitParams = NoParams;
|
2017-10-12 21:29:58 +08:00
|
|
|
|
[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
|
|
|
/// Defines how the host (editor) should sync document changes to the language
|
|
|
|
/// server.
|
|
|
|
enum class TextDocumentSyncKind {
|
|
|
|
/// Documents should not be synced at all.
|
|
|
|
None = 0,
|
|
|
|
|
|
|
|
/// Documents are synced by always sending the full content of the document.
|
|
|
|
Full = 1,
|
|
|
|
|
|
|
|
/// Documents are synced by sending the full content on open. After that
|
|
|
|
/// only incremental updates to the document are send.
|
|
|
|
Incremental = 2,
|
|
|
|
};
|
|
|
|
|
2018-09-28 01:13:07 +08:00
|
|
|
/// The kind of a completion entry.
|
|
|
|
enum class CompletionItemKind {
|
|
|
|
Missing = 0,
|
|
|
|
Text = 1,
|
|
|
|
Method = 2,
|
|
|
|
Function = 3,
|
|
|
|
Constructor = 4,
|
|
|
|
Field = 5,
|
|
|
|
Variable = 6,
|
|
|
|
Class = 7,
|
|
|
|
Interface = 8,
|
|
|
|
Module = 9,
|
|
|
|
Property = 10,
|
|
|
|
Unit = 11,
|
|
|
|
Value = 12,
|
|
|
|
Enum = 13,
|
|
|
|
Keyword = 14,
|
|
|
|
Snippet = 15,
|
|
|
|
Color = 16,
|
|
|
|
File = 17,
|
|
|
|
Reference = 18,
|
|
|
|
Folder = 19,
|
|
|
|
EnumMember = 20,
|
|
|
|
Constant = 21,
|
|
|
|
Struct = 22,
|
|
|
|
Event = 23,
|
|
|
|
Operator = 24,
|
|
|
|
TypeParameter = 25,
|
|
|
|
};
|
[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 &, CompletionItemKind &,
|
|
|
|
llvm::json::Path);
|
2018-09-28 01:13:07 +08:00
|
|
|
constexpr auto CompletionItemKindMin =
|
|
|
|
static_cast<size_t>(CompletionItemKind::Text);
|
|
|
|
constexpr auto CompletionItemKindMax =
|
|
|
|
static_cast<size_t>(CompletionItemKind::TypeParameter);
|
|
|
|
using CompletionItemKindBitset = std::bitset<CompletionItemKindMax + 1>;
|
[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 &, CompletionItemKindBitset &,
|
|
|
|
llvm::json::Path);
|
2018-09-28 01:13:07 +08:00
|
|
|
CompletionItemKind
|
|
|
|
adjustKindToCapability(CompletionItemKind Kind,
|
2019-05-03 16:03:21 +08:00
|
|
|
CompletionItemKindBitset &SupportedCompletionItemKinds);
|
2018-09-28 01:13:07 +08:00
|
|
|
|
[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
|
|
|
/// A symbol kind.
|
|
|
|
enum class SymbolKind {
|
|
|
|
File = 1,
|
|
|
|
Module = 2,
|
|
|
|
Namespace = 3,
|
|
|
|
Package = 4,
|
|
|
|
Class = 5,
|
|
|
|
Method = 6,
|
|
|
|
Property = 7,
|
|
|
|
Field = 8,
|
|
|
|
Constructor = 9,
|
|
|
|
Enum = 10,
|
|
|
|
Interface = 11,
|
|
|
|
Function = 12,
|
|
|
|
Variable = 13,
|
|
|
|
Constant = 14,
|
|
|
|
String = 15,
|
|
|
|
Number = 16,
|
|
|
|
Boolean = 17,
|
|
|
|
Array = 18,
|
|
|
|
Object = 19,
|
|
|
|
Key = 20,
|
|
|
|
Null = 21,
|
|
|
|
EnumMember = 22,
|
|
|
|
Struct = 23,
|
|
|
|
Event = 24,
|
|
|
|
Operator = 25,
|
|
|
|
TypeParameter = 26
|
|
|
|
};
|
[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 &, SymbolKind &, llvm::json::Path);
|
[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
|
|
|
constexpr auto SymbolKindMin = static_cast<size_t>(SymbolKind::File);
|
|
|
|
constexpr auto SymbolKindMax = static_cast<size_t>(SymbolKind::TypeParameter);
|
|
|
|
using SymbolKindBitset = std::bitset<SymbolKindMax + 1>;
|
[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 &, SymbolKindBitset &, llvm::json::Path);
|
[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
|
|
|
SymbolKind adjustKindToCapability(SymbolKind Kind,
|
|
|
|
SymbolKindBitset &supportedSymbolKinds);
|
|
|
|
|
[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
|
|
|
// Convert a index::SymbolKind to clangd::SymbolKind (LSP)
|
|
|
|
// Note, some are not perfect matches and should be improved when this LSP
|
|
|
|
// issue is addressed:
|
|
|
|
// https://github.com/Microsoft/language-server-protocol/issues/344
|
|
|
|
SymbolKind indexSymbolKindToSymbolKind(index::SymbolKind Kind);
|
|
|
|
|
2019-03-28 01:47:49 +08:00
|
|
|
// Determines the encoding used to measure offsets and lengths of source in LSP.
|
|
|
|
enum class OffsetEncoding {
|
|
|
|
// Any string is legal on the wire. Unrecognized encodings parse as this.
|
|
|
|
UnsupportedEncoding,
|
|
|
|
// Length counts code units of UTF-16 encoded text. (Standard LSP behavior).
|
|
|
|
UTF16,
|
|
|
|
// Length counts bytes of UTF-8 encoded text. (Clangd extension).
|
|
|
|
UTF8,
|
2019-03-28 22:37:51 +08:00
|
|
|
// Length counts codepoints in unicode text. (Clangd extension).
|
|
|
|
UTF32,
|
2019-03-28 01:47:49 +08:00
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const OffsetEncoding &);
|
[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 &, OffsetEncoding &, llvm::json::Path);
|
2019-05-03 16:03:21 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &, OffsetEncoding);
|
2019-03-28 01:47:49 +08:00
|
|
|
|
2019-05-29 18:01:00 +08:00
|
|
|
// Describes the content type that a client supports in various result literals
|
|
|
|
// like `Hover`, `ParameterInfo` or `CompletionItem`.
|
|
|
|
enum class MarkupKind {
|
|
|
|
PlainText,
|
|
|
|
Markdown,
|
|
|
|
};
|
[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 &, MarkupKind &, llvm::json::Path);
|
2019-05-29 18:01:00 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, MarkupKind);
|
|
|
|
|
2018-10-17 15:33:42 +08:00
|
|
|
// This struct doesn't mirror LSP!
|
|
|
|
// The protocol defines deeply nested structures for client capabilities.
|
|
|
|
// Instead of mapping them all, this just parses out the bits we care about.
|
|
|
|
struct ClientCapabilities {
|
|
|
|
/// The supported set of SymbolKinds for workspace/symbol.
|
|
|
|
/// workspace.symbol.symbolKind.valueSet
|
|
|
|
llvm::Optional<SymbolKindBitset> WorkspaceSymbolKinds;
|
[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
|
|
|
|
[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
|
|
|
/// Whether the client accepts diagnostics with codeActions attached inline.
|
|
|
|
/// textDocument.publishDiagnostics.codeActionsInline.
|
2018-10-17 15:33:42 +08:00
|
|
|
bool DiagnosticFixes = false;
|
2018-08-11 01:25:07 +08:00
|
|
|
|
2019-04-18 23:17:07 +08:00
|
|
|
/// Whether the client accepts diagnostics with related locations.
|
|
|
|
/// textDocument.publishDiagnostics.relatedInformation.
|
|
|
|
bool DiagnosticRelatedInformation = false;
|
|
|
|
|
2018-10-17 15:33:42 +08:00
|
|
|
/// Whether the client accepts diagnostics with category attached to it
|
|
|
|
/// using the "category" extension.
|
|
|
|
/// textDocument.publishDiagnostics.categorySupport
|
|
|
|
bool DiagnosticCategory = false;
|
2018-10-17 00:29:41 +08:00
|
|
|
|
2018-10-17 15:33:42 +08:00
|
|
|
/// Client supports snippets as insert text.
|
|
|
|
/// textDocument.completion.completionItem.snippetSupport
|
|
|
|
bool CompletionSnippets = false;
|
2018-02-15 22:32:57 +08:00
|
|
|
|
2019-06-18 19:57:26 +08:00
|
|
|
/// Client supports completions with additionalTextEdit near the cursor.
|
|
|
|
/// This is a clangd extension. (LSP says this is for unrelated text only).
|
|
|
|
/// textDocument.completion.editsNearCursor
|
|
|
|
bool CompletionFixes = false;
|
|
|
|
|
2018-11-23 23:21:19 +08:00
|
|
|
/// Client supports hierarchical document symbols.
|
2019-07-09 01:27:15 +08:00
|
|
|
/// textDocument.documentSymbol.hierarchicalDocumentSymbolSupport
|
2018-11-23 23:21:19 +08:00
|
|
|
bool HierarchicalDocumentSymbol = false;
|
|
|
|
|
2019-07-09 01:27:15 +08:00
|
|
|
/// Client supports signature help.
|
|
|
|
/// textDocument.signatureHelp
|
|
|
|
bool HasSignatureHelp = false;
|
|
|
|
|
2019-06-04 17:36:59 +08:00
|
|
|
/// Client supports processing label offsets instead of a simple label string.
|
2019-07-09 01:27:15 +08:00
|
|
|
/// textDocument.signatureHelp.signatureInformation.parameterInformation.labelOffsetSupport
|
2019-06-04 17:36:59 +08:00
|
|
|
bool OffsetsInSignatureHelp = false;
|
|
|
|
|
2018-10-17 15:33:42 +08:00
|
|
|
/// The supported set of CompletionItemKinds for textDocument/completion.
|
|
|
|
/// textDocument.completion.completionItemKind.valueSet
|
|
|
|
llvm::Optional<CompletionItemKindBitset> CompletionItemKinds;
|
2018-02-15 22:32:57 +08:00
|
|
|
|
2020-04-30 16:49:32 +08:00
|
|
|
/// The documentation format that should be used for textDocument/completion.
|
|
|
|
/// textDocument.completion.completionItem.documentationFormat
|
|
|
|
MarkupKind CompletionDocumentationFormat = MarkupKind::PlainText;
|
|
|
|
|
2018-10-17 15:33:42 +08:00
|
|
|
/// Client supports CodeAction return value for textDocument/codeAction.
|
|
|
|
/// textDocument.codeAction.codeActionLiteralSupport.
|
|
|
|
bool CodeActionStructure = false;
|
2019-03-28 01:47:49 +08:00
|
|
|
|
2020-04-01 18:02:28 +08:00
|
|
|
/// Client advertises support for the semanticTokens feature.
|
|
|
|
/// We support the textDocument/semanticTokens request in any case.
|
|
|
|
/// textDocument.semanticTokens
|
|
|
|
bool SemanticTokens = false;
|
2020-03-24 07:31:14 +08:00
|
|
|
/// Client supports Theia semantic highlighting extension.
|
|
|
|
/// https://github.com/microsoft/vscode-languageserver-node/pull/367
|
2020-04-01 18:02:28 +08:00
|
|
|
/// This will be ignored if the client also supports semanticTokens.
|
2019-07-09 01:27:15 +08:00
|
|
|
/// textDocument.semanticHighlightingCapabilities.semanticHighlighting
|
2020-03-24 07:31:14 +08:00
|
|
|
/// FIXME: drop this support once clients support LSP 3.16 Semantic Tokens.
|
|
|
|
bool TheiaSemanticHighlighting = false;
|
2019-07-04 15:53:12 +08:00
|
|
|
|
2019-03-28 01:47:49 +08:00
|
|
|
/// Supported encodings for LSP character offsets. (clangd extension).
|
|
|
|
llvm::Optional<std::vector<OffsetEncoding>> offsetEncoding;
|
2019-05-29 18:01:00 +08:00
|
|
|
|
|
|
|
/// The content format that should be used for Hover requests.
|
2019-07-09 01:27:15 +08:00
|
|
|
/// textDocument.hover.contentEncoding
|
2019-05-29 18:01:00 +08:00
|
|
|
MarkupKind HoverContentFormat = MarkupKind::PlainText;
|
2019-07-24 15:49:23 +08:00
|
|
|
|
|
|
|
/// The client supports testing for validity of rename operations
|
|
|
|
/// before execution.
|
|
|
|
bool RenamePrepareSupport = false;
|
[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
|
|
|
|
|
|
|
/// The client supports progress notifications.
|
|
|
|
/// window.workDoneProgress
|
|
|
|
bool WorkDoneProgress = false;
|
|
|
|
|
|
|
|
/// The client supports implicit $/progress work-done progress streams,
|
|
|
|
/// without a preceding window/workDoneProgress/create.
|
|
|
|
/// This is a clangd extension.
|
|
|
|
/// window.implicitWorkDoneProgressCreate
|
|
|
|
bool ImplicitProgressCreation = false;
|
2018-02-15 22:32:57 +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 &, ClientCapabilities &,
|
|
|
|
llvm::json::Path);
|
2018-02-15 22:32:57 +08:00
|
|
|
|
2018-08-02 01:39:29 +08:00
|
|
|
/// Clangd extension that's used in the 'compilationDatabaseChanges' in
|
|
|
|
/// workspace/didChangeConfiguration to record updates to the in-memory
|
|
|
|
/// compilation database.
|
|
|
|
struct ClangdCompileCommand {
|
|
|
|
std::string workingDirectory;
|
|
|
|
std::vector<std::string> 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 &, ClangdCompileCommand &,
|
|
|
|
llvm::json::Path);
|
2018-08-02 01:39:29 +08:00
|
|
|
|
2018-10-25 12:22:52 +08:00
|
|
|
/// Clangd extension: parameters configurable at any time, via the
|
|
|
|
/// `workspace/didChangeConfiguration` notification.
|
|
|
|
/// LSP defines this type as `any`.
|
|
|
|
struct ConfigurationSettings {
|
|
|
|
// Changes to the in-memory compilation database.
|
2018-08-02 01:39:29 +08:00
|
|
|
// The key of the map is a file name.
|
2018-10-25 12:22:52 +08:00
|
|
|
std::map<std::string, ClangdCompileCommand> compilationDatabaseChanges;
|
2018-08-01 19:28: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 &, ConfigurationSettings &,
|
|
|
|
llvm::json::Path);
|
2018-08-01 19:28:49 +08:00
|
|
|
|
2018-10-25 12:22:52 +08:00
|
|
|
/// Clangd extension: parameters configurable at `initialize` time.
|
|
|
|
/// LSP defines this type as `any`.
|
|
|
|
struct InitializationOptions {
|
2018-10-16 23:55:03 +08:00
|
|
|
// What we can change throught the didChangeConfiguration request, we can
|
|
|
|
// also set through the initialize request (initializationOptions field).
|
2018-10-25 12:22:52 +08:00
|
|
|
ConfigurationSettings ConfigSettings;
|
2018-10-16 23:55:03 +08:00
|
|
|
|
|
|
|
llvm::Optional<std::string> compilationDatabasePath;
|
2018-11-02 22:07:51 +08:00
|
|
|
// Additional flags to be included in the "fallback command" used when
|
|
|
|
// the compilation database doesn't describe an opened file.
|
|
|
|
// The command used will be approximately `clang $FILE $fallbackFlags`.
|
|
|
|
std::vector<std::string> fallbackFlags;
|
2018-12-20 23:39:12 +08:00
|
|
|
|
|
|
|
/// Clients supports show file status for textDocument/clangd.fileStatus.
|
|
|
|
bool FileStatus = false;
|
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 &, InitializationOptions &,
|
|
|
|
llvm::json::Path);
|
2018-08-01 19:28:49 +08:00
|
|
|
|
2017-09-27 23:31:17 +08:00
|
|
|
struct InitializeParams {
|
|
|
|
/// The process Id of the parent process that started
|
|
|
|
/// the server. Is null if the process has not been started by another
|
|
|
|
/// process. If the parent process is not alive then the server should exit
|
|
|
|
/// (see exit notification) its process.
|
|
|
|
llvm::Optional<int> processId;
|
|
|
|
|
|
|
|
/// The rootPath of the workspace. Is null
|
|
|
|
/// if no folder is open.
|
|
|
|
///
|
|
|
|
/// @deprecated in favour of rootUri.
|
|
|
|
llvm::Optional<std::string> rootPath;
|
|
|
|
|
|
|
|
/// The rootUri of the workspace. Is null if no
|
|
|
|
/// folder is open. If both `rootPath` and `rootUri` are set
|
|
|
|
/// `rootUri` wins.
|
2018-01-29 23:37:46 +08:00
|
|
|
llvm::Optional<URIForFile> rootUri;
|
2017-09-27 23:31:17 +08:00
|
|
|
|
|
|
|
// User provided initialization options.
|
|
|
|
// initializationOptions?: any;
|
|
|
|
|
|
|
|
/// The capabilities provided by the client (editor or tool)
|
2018-02-15 22:32:57 +08:00
|
|
|
ClientCapabilities capabilities;
|
2017-09-27 23:31:17 +08:00
|
|
|
|
|
|
|
/// The initial trace setting. If omitted trace is disabled ('off').
|
|
|
|
llvm::Optional<TraceLevel> trace;
|
2018-08-01 19:28:49 +08:00
|
|
|
|
2018-10-25 12:22:52 +08:00
|
|
|
/// User-provided initialization options.
|
|
|
|
InitializationOptions initializationOptions;
|
2017-09-27 23:31:17 +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 &, InitializeParams &, llvm::json::Path);
|
2017-09-27 23:31:17 +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
|
|
|
struct WorkDoneProgressCreateParams {
|
|
|
|
/// The token to be used to report progress.
|
|
|
|
llvm::json::Value token = nullptr;
|
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const WorkDoneProgressCreateParams &P);
|
|
|
|
|
|
|
|
template <typename T> struct ProgressParams {
|
|
|
|
/// The progress token provided by the client or server.
|
|
|
|
llvm::json::Value token = nullptr;
|
|
|
|
|
|
|
|
/// The progress data.
|
|
|
|
T value;
|
|
|
|
};
|
|
|
|
template <typename T> llvm::json::Value toJSON(const ProgressParams<T> &P) {
|
|
|
|
return llvm::json::Object{{"token", P.token}, {"value", P.value}};
|
|
|
|
}
|
|
|
|
/// To start progress reporting a $/progress notification with the following
|
|
|
|
/// payload must be sent.
|
|
|
|
struct WorkDoneProgressBegin {
|
|
|
|
/// Mandatory title of the progress operation. Used to briefly inform about
|
|
|
|
/// the kind of operation being performed.
|
|
|
|
///
|
|
|
|
/// Examples: "Indexing" or "Linking dependencies".
|
|
|
|
std::string title;
|
|
|
|
|
|
|
|
/// Controls if a cancel button should show to allow the user to cancel the
|
|
|
|
/// long-running operation. Clients that don't support cancellation are
|
|
|
|
/// allowed to ignore the setting.
|
|
|
|
bool cancellable = false;
|
|
|
|
|
|
|
|
/// Optional progress percentage to display (value 100 is considered 100%).
|
|
|
|
/// If not provided infinite progress is assumed and clients are allowed
|
|
|
|
/// to ignore the `percentage` value in subsequent in report notifications.
|
|
|
|
///
|
|
|
|
/// The value should be steadily rising. Clients are free to ignore values
|
|
|
|
/// that are not following this rule.
|
|
|
|
///
|
|
|
|
/// Clangd implementation note: we only send nonzero percentages in
|
|
|
|
/// the WorkProgressReport. 'true' here means percentages will be used.
|
|
|
|
bool percentage = false;
|
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const WorkDoneProgressBegin &);
|
|
|
|
|
|
|
|
/// Reporting progress is done using the following payload.
|
|
|
|
struct WorkDoneProgressReport {
|
|
|
|
/// Mandatory title of the progress operation. Used to briefly inform about
|
|
|
|
/// the kind of operation being performed.
|
|
|
|
///
|
|
|
|
/// Examples: "Indexing" or "Linking dependencies".
|
|
|
|
std::string title;
|
|
|
|
|
|
|
|
/// Controls enablement state of a cancel button. This property is only valid
|
|
|
|
/// if a cancel button got requested in the `WorkDoneProgressStart` payload.
|
|
|
|
///
|
|
|
|
/// Clients that don't support cancellation or don't support control
|
|
|
|
/// the button's enablement state are allowed to ignore the setting.
|
|
|
|
llvm::Optional<bool> cancellable;
|
|
|
|
|
|
|
|
/// Optional, more detailed associated progress message. Contains
|
|
|
|
/// complementary information to the `title`.
|
|
|
|
///
|
|
|
|
/// Examples: "3/25 files", "project/src/module2", "node_modules/some_dep".
|
|
|
|
/// If unset, the previous progress message (if any) is still valid.
|
|
|
|
llvm::Optional<std::string> message;
|
|
|
|
|
|
|
|
/// Optional progress percentage to display (value 100 is considered 100%).
|
|
|
|
/// If not provided infinite progress is assumed and clients are allowed
|
|
|
|
/// to ignore the `percentage` value in subsequent in report notifications.
|
|
|
|
///
|
|
|
|
/// The value should be steadily rising. Clients are free to ignore values
|
|
|
|
/// that are not following this rule.
|
|
|
|
llvm::Optional<double> percentage;
|
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const WorkDoneProgressReport &);
|
|
|
|
//
|
|
|
|
/// Signals the end of progress reporting.
|
|
|
|
struct WorkDoneProgressEnd {
|
|
|
|
/// Optional, a final message indicating to for example indicate the outcome
|
|
|
|
/// of the operation.
|
|
|
|
llvm::Optional<std::string> message;
|
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const WorkDoneProgressEnd &);
|
|
|
|
|
2019-06-18 21:37:54 +08:00
|
|
|
enum class MessageType {
|
|
|
|
/// An error message.
|
|
|
|
Error = 1,
|
|
|
|
/// A warning message.
|
2019-06-19 21:14:59 +08:00
|
|
|
Warning = 2,
|
2019-06-18 21:37:54 +08:00
|
|
|
/// An information message.
|
2019-06-19 21:14:59 +08:00
|
|
|
Info = 3,
|
2019-06-18 21:37:54 +08:00
|
|
|
/// A log message.
|
2019-06-19 21:14:59 +08:00
|
|
|
Log = 4,
|
2019-06-18 21:37:54 +08:00
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const MessageType &);
|
|
|
|
|
|
|
|
/// The show message notification is sent from a server to a client to ask the
|
|
|
|
/// client to display a particular message in the user interface.
|
|
|
|
struct ShowMessageParams {
|
|
|
|
/// The message type.
|
|
|
|
MessageType type = MessageType::Info;
|
|
|
|
/// The actual message.
|
|
|
|
std::string message;
|
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const ShowMessageParams &);
|
|
|
|
|
2017-02-07 18:28:20 +08:00
|
|
|
struct DidOpenTextDocumentParams {
|
|
|
|
/// The document that was opened.
|
|
|
|
TextDocumentItem 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 &, DidOpenTextDocumentParams &,
|
|
|
|
llvm::json::Path);
|
2017-02-07 18:28:20 +08:00
|
|
|
|
2017-04-10 21:31:39 +08:00
|
|
|
struct DidCloseTextDocumentParams {
|
|
|
|
/// The document that was closed.
|
|
|
|
TextDocumentIdentifier 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 &, DidCloseTextDocumentParams &,
|
|
|
|
llvm::json::Path);
|
2017-04-10 21:31:39 +08:00
|
|
|
|
2020-04-10 09:27:37 +08:00
|
|
|
struct DidSaveTextDocumentParams {
|
|
|
|
/// The document that was saved.
|
|
|
|
TextDocumentIdentifier 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 &, DidSaveTextDocumentParams &,
|
|
|
|
llvm::json::Path);
|
2020-04-10 09:27:37 +08:00
|
|
|
|
2017-02-07 18:28:20 +08:00
|
|
|
struct TextDocumentContentChangeEvent {
|
[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
|
|
|
/// The range of the document that changed.
|
|
|
|
llvm::Optional<Range> range;
|
|
|
|
|
|
|
|
/// The length of the range that got replaced.
|
|
|
|
llvm::Optional<int> rangeLength;
|
|
|
|
|
|
|
|
/// The new text of the range/document.
|
2017-02-07 18:28:20 +08:00
|
|
|
std::string 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 &, TextDocumentContentChangeEvent &,
|
|
|
|
llvm::json::Path);
|
2017-02-07 18:28:20 +08:00
|
|
|
|
|
|
|
struct DidChangeTextDocumentParams {
|
|
|
|
/// The document that did change. The version number points
|
|
|
|
/// to the version after all provided content changes have
|
|
|
|
/// been applied.
|
2020-03-03 22:57:39 +08:00
|
|
|
VersionedTextDocumentIdentifier textDocument;
|
2017-02-07 18:28:20 +08:00
|
|
|
|
|
|
|
/// The actual content changes.
|
|
|
|
std::vector<TextDocumentContentChangeEvent> contentChanges;
|
2018-02-23 02:40:39 +08:00
|
|
|
|
|
|
|
/// Forces diagnostics to be generated, or to not be generated, for this
|
|
|
|
/// version of the file. If not set, diagnostics are eventually consistent:
|
|
|
|
/// either they will be provided for this version or some subsequent one.
|
|
|
|
/// This is a clangd extension.
|
|
|
|
llvm::Optional<bool> wantDiagnostics;
|
2020-02-04 04:14:49 +08:00
|
|
|
|
|
|
|
/// Force a complete rebuild of the file, ignoring all cached state. Slow!
|
|
|
|
/// This is useful to defeat clangd's assumption that missing headers will
|
|
|
|
/// stay missing.
|
|
|
|
/// This is a clangd extension.
|
|
|
|
bool forceRebuild = false;
|
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 &, DidChangeTextDocumentParams &,
|
|
|
|
llvm::json::Path);
|
2017-02-07 18:28:20 +08:00
|
|
|
|
2017-10-03 02:00:37 +08:00
|
|
|
enum class FileChangeType {
|
|
|
|
/// The file got created.
|
|
|
|
Created = 1,
|
|
|
|
/// The file got changed.
|
|
|
|
Changed = 2,
|
|
|
|
/// The file got deleted.
|
|
|
|
Deleted = 3
|
|
|
|
};
|
[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);
|
2017-10-03 02:00:37 +08:00
|
|
|
|
|
|
|
struct FileEvent {
|
|
|
|
/// The file's URI.
|
2018-01-29 23:37:46 +08:00
|
|
|
URIForFile uri;
|
2017-10-03 02:00:37 +08:00
|
|
|
/// The change type.
|
2018-02-14 18:52:04 +08:00
|
|
|
FileChangeType type = FileChangeType::Created;
|
2017-10-03 02:00:37 +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 &, FileEvent &, llvm::json::Path);
|
2017-10-03 02:00:37 +08:00
|
|
|
|
|
|
|
struct DidChangeWatchedFilesParams {
|
|
|
|
/// The actual file events.
|
|
|
|
std::vector<FileEvent> changes;
|
|
|
|
};
|
[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 &, DidChangeWatchedFilesParams &,
|
|
|
|
llvm::json::Path);
|
2017-10-03 02:00:37 +08:00
|
|
|
|
[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
|
|
|
struct DidChangeConfigurationParams {
|
2018-10-25 12:22:52 +08:00
|
|
|
ConfigurationSettings settings;
|
[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 &, DidChangeConfigurationParams &,
|
|
|
|
llvm::json::Path);
|
[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
|
|
|
|
2019-06-10 21:01:49 +08:00
|
|
|
// Note: we do not parse FormattingOptions for *FormattingParams.
|
|
|
|
// In general, we use a clang-format style detected from common mechanisms
|
|
|
|
// (.clang-format files and the -fallback-style flag).
|
|
|
|
// It would be possible to override these with FormatOptions, but:
|
|
|
|
// - the protocol makes FormatOptions mandatory, so many clients set them to
|
|
|
|
// useless values, and we can't tell when to respect them
|
|
|
|
// - we also format in other places, where FormatOptions aren't available.
|
2017-02-07 18:28:20 +08:00
|
|
|
|
|
|
|
struct DocumentRangeFormattingParams {
|
|
|
|
/// The document to format.
|
|
|
|
TextDocumentIdentifier textDocument;
|
|
|
|
|
|
|
|
/// The range to format
|
|
|
|
Range range;
|
|
|
|
};
|
[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 &, DocumentRangeFormattingParams &,
|
|
|
|
llvm::json::Path);
|
2017-02-07 18:28:20 +08:00
|
|
|
|
2017-02-16 18:49:46 +08:00
|
|
|
struct DocumentOnTypeFormattingParams {
|
|
|
|
/// The document to format.
|
|
|
|
TextDocumentIdentifier textDocument;
|
|
|
|
|
|
|
|
/// The position at which this request was sent.
|
|
|
|
Position position;
|
|
|
|
|
|
|
|
/// The character that has been typed.
|
|
|
|
std::string ch;
|
|
|
|
};
|
[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 &, DocumentOnTypeFormattingParams &,
|
|
|
|
llvm::json::Path);
|
2017-02-16 18:49:46 +08:00
|
|
|
|
2017-02-07 18:28:20 +08:00
|
|
|
struct DocumentFormattingParams {
|
|
|
|
/// The document to format.
|
|
|
|
TextDocumentIdentifier 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 &, DocumentFormattingParams &,
|
|
|
|
llvm::json::Path);
|
2017-02-07 18:28:20 +08:00
|
|
|
|
2018-07-06 03:35:01 +08:00
|
|
|
struct DocumentSymbolParams {
|
|
|
|
// The text document to find symbols in.
|
|
|
|
TextDocumentIdentifier 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 &, DocumentSymbolParams &,
|
|
|
|
llvm::json::Path);
|
2018-07-06 03:35:01 +08:00
|
|
|
|
2019-04-18 23:17:07 +08:00
|
|
|
/// Represents a related message and source code location for a diagnostic.
|
|
|
|
/// This should be used to point to code locations that cause or related to a
|
|
|
|
/// diagnostics, e.g when duplicating a symbol in a scope.
|
|
|
|
struct DiagnosticRelatedInformation {
|
|
|
|
/// The location of this related diagnostic information.
|
|
|
|
Location location;
|
|
|
|
/// The message of this related diagnostic information.
|
|
|
|
std::string message;
|
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const DiagnosticRelatedInformation &);
|
|
|
|
|
[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
|
|
|
struct CodeAction;
|
2017-03-02 00:16:29 +08:00
|
|
|
struct Diagnostic {
|
|
|
|
/// The range at which the message applies.
|
|
|
|
Range range;
|
|
|
|
|
|
|
|
/// The diagnostic's severity. Can be omitted. If omitted it is up to the
|
|
|
|
/// client to interpret diagnostics as error, warning, info or hint.
|
2018-02-14 18:52:04 +08:00
|
|
|
int severity = 0;
|
2017-03-02 00:16:29 +08:00
|
|
|
|
2017-09-18 23:02:59 +08:00
|
|
|
/// The diagnostic's code. Can be omitted.
|
2019-04-17 20:35:16 +08:00
|
|
|
std::string code;
|
2017-09-18 23:02:59 +08:00
|
|
|
|
|
|
|
/// A human-readable string describing the source of this
|
|
|
|
/// diagnostic, e.g. 'typescript' or 'super lint'.
|
2019-04-17 20:35:16 +08:00
|
|
|
std::string source;
|
2017-09-18 23:02:59 +08:00
|
|
|
|
2017-03-02 00:16:29 +08:00
|
|
|
/// The diagnostic's message.
|
|
|
|
std::string message;
|
2018-08-15 06:21:40 +08:00
|
|
|
|
2019-04-18 23:17:07 +08:00
|
|
|
/// An array of related diagnostic information, e.g. when symbol-names within
|
|
|
|
/// a scope collide all definitions can be marked via this property.
|
|
|
|
llvm::Optional<std::vector<DiagnosticRelatedInformation>> relatedInformation;
|
|
|
|
|
2018-08-15 06:21:40 +08:00
|
|
|
/// The diagnostic's category. Can be omitted.
|
|
|
|
/// An LSP extension that's used to send the name of the category over to the
|
|
|
|
/// client. The category typically describes the compilation stage during
|
|
|
|
/// which the issue was produced, e.g. "Semantic Issue" or "Parse Issue".
|
[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
|
|
|
llvm::Optional<std::string> category;
|
|
|
|
|
|
|
|
/// Clangd extension: code actions related to this diagnostic.
|
|
|
|
/// Only with capability textDocument.publishDiagnostics.codeActionsInline.
|
|
|
|
/// (These actions can also be obtained using textDocument/codeAction).
|
|
|
|
llvm::Optional<std::vector<CodeAction>> codeActions;
|
2017-12-20 04:52:56 +08:00
|
|
|
};
|
2018-10-17 00:29:41 +08:00
|
|
|
llvm::json::Value toJSON(const Diagnostic &);
|
2018-03-12 23:28:22 +08:00
|
|
|
|
2017-12-20 04:52:56 +08:00
|
|
|
/// A LSP-specific comparator used to find diagnostic in a container like
|
|
|
|
/// std:map.
|
2020-01-04 23:28:41 +08:00
|
|
|
/// We only use the required fields of Diagnostic to do the comparison to avoid
|
2019-07-05 20:57:56 +08:00
|
|
|
/// any regression issues from LSP clients (e.g. VScode), see
|
|
|
|
/// https://git.io/vbr29
|
2017-12-20 04:52:56 +08:00
|
|
|
struct LSPDiagnosticCompare {
|
2018-03-12 23:28:22 +08:00
|
|
|
bool operator()(const Diagnostic &LHS, const Diagnostic &RHS) const {
|
2017-12-20 04:52:56 +08:00
|
|
|
return std::tie(LHS.range, LHS.message) < std::tie(RHS.range, RHS.message);
|
2017-03-02 00:16: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 &, Diagnostic &, llvm::json::Path);
|
2018-01-26 01:29:17 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &, const Diagnostic &);
|
2017-03-02 00:16:29 +08:00
|
|
|
|
2020-03-03 19:44:40 +08:00
|
|
|
struct PublishDiagnosticsParams {
|
|
|
|
/// The URI for which diagnostic information is reported.
|
|
|
|
URIForFile uri;
|
|
|
|
/// An array of diagnostic information items.
|
|
|
|
std::vector<Diagnostic> diagnostics;
|
[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
|
|
|
/// The version number of the document the diagnostics are published for.
|
|
|
|
llvm::Optional<int64_t> version;
|
2020-03-03 19:44:40 +08:00
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const PublishDiagnosticsParams &);
|
|
|
|
|
2017-03-02 00:16:29 +08:00
|
|
|
struct CodeActionContext {
|
2020-10-09 21:17:26 +08:00
|
|
|
/// An array of diagnostics known on the client side overlapping the range
|
|
|
|
/// provided to the `textDocument/codeAction` request. They are provided so
|
|
|
|
/// that the server knows which errors are currently presented to the user for
|
|
|
|
/// the given range. There is no guarantee that these accurately reflect the
|
|
|
|
/// error state of the resource. The primary parameter to compute code actions
|
|
|
|
/// is the provided range.
|
2017-03-02 00:16:29 +08:00
|
|
|
std::vector<Diagnostic> diagnostics;
|
2020-10-09 21:17:26 +08:00
|
|
|
|
|
|
|
/// Requested kind of actions to return.
|
|
|
|
///
|
|
|
|
/// Actions not of this kind are filtered out by the client before being
|
|
|
|
/// shown. So servers can omit computing them.
|
|
|
|
std::vector<std::string> only;
|
2017-03-02 00:16: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 &, CodeActionContext &, llvm::json::Path);
|
2017-03-02 00:16:29 +08:00
|
|
|
|
|
|
|
struct CodeActionParams {
|
|
|
|
/// The document in which the command was invoked.
|
|
|
|
TextDocumentIdentifier textDocument;
|
|
|
|
|
|
|
|
/// The range for which the command was invoked.
|
|
|
|
Range range;
|
|
|
|
|
|
|
|
/// Context carrying additional information.
|
|
|
|
CodeActionContext 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 &, CodeActionParams &, llvm::json::Path);
|
2017-03-02 00:16:29 +08:00
|
|
|
|
[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
|
|
|
struct WorkspaceEdit {
|
|
|
|
/// Holds changes to existing resources.
|
|
|
|
llvm::Optional<std::map<std::string, std::vector<TextEdit>>> changes;
|
|
|
|
|
|
|
|
/// Note: "documentChanges" is not currently used because currently there is
|
|
|
|
/// no support for versioned edits.
|
|
|
|
};
|
[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 &, WorkspaceEdit &, llvm::json::Path);
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const WorkspaceEdit &WE);
|
[clangd] Handle clangd.applyFix server-side
Summary:
When the user selects a fix-it (or any code action with commands), it is
possible to let the client forward the selected command to the server.
When the clangd.applyFix command is handled on the server, it can send a
workspace/applyEdit request to the client. This has the advantage that
the client doesn't explicitly have to know how to handle
clangd.applyFix. Therefore, the code to handle clangd.applyFix in the VS
Code extension (and any other Clangd client) is not required anymore.
Reviewers: ilya-biryukov, sammccall, Nebiroth, hokein
Reviewed By: hokein
Subscribers: ioeric, hokein, rwols, puremourning, bkramer, ilya-biryukov
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D39276
llvm-svn: 317322
2017-11-03 21:39:15 +08:00
|
|
|
|
[clangd] 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
|
|
|
/// Arguments for the 'applyTweak' command. The server sends these commands as a
|
|
|
|
/// response to the textDocument/codeAction request. The client can later send a
|
|
|
|
/// command back to the server if the user requests to execute a particular code
|
|
|
|
/// tweak.
|
|
|
|
struct TweakArgs {
|
|
|
|
/// A file provided by the client on a textDocument/codeAction request.
|
|
|
|
URIForFile file;
|
|
|
|
/// A selection provided by the client on a textDocument/codeAction request.
|
|
|
|
Range selection;
|
|
|
|
/// ID of the tweak that should be executed. Corresponds to Tweak::id().
|
|
|
|
std::string tweakID;
|
|
|
|
};
|
[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 &, TweakArgs &, llvm::json::Path);
|
[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
|
|
|
llvm::json::Value toJSON(const TweakArgs &A);
|
|
|
|
|
[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
|
|
|
/// Exact commands are not specified in the protocol so we define the
|
|
|
|
/// ones supported by Clangd here. The protocol specifies the command arguments
|
|
|
|
/// to be "any[]" but to make this safer and more manageable, each command we
|
|
|
|
/// handle maps to a certain llvm::Optional of some struct to contain its
|
|
|
|
/// arguments. Different commands could reuse the same llvm::Optional as
|
|
|
|
/// arguments but a command that needs different arguments would simply add a
|
|
|
|
/// new llvm::Optional and not use any other ones. In practice this means only
|
|
|
|
/// one argument type will be parsed and set.
|
|
|
|
struct ExecuteCommandParams {
|
|
|
|
// Command to apply fix-its. Uses WorkspaceEdit as argument.
|
2017-12-28 23:03:02 +08:00
|
|
|
const static llvm::StringLiteral CLANGD_APPLY_FIX_COMMAND;
|
[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
|
|
|
// Command to apply the code action. Uses TweakArgs as argument.
|
|
|
|
const static llvm::StringLiteral CLANGD_APPLY_TWEAK;
|
[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
|
|
|
|
|
|
|
/// The command identifier, e.g. CLANGD_APPLY_FIX_COMMAND
|
|
|
|
std::string command;
|
|
|
|
|
|
|
|
// Arguments
|
|
|
|
llvm::Optional<WorkspaceEdit> workspaceEdit;
|
[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
|
|
|
llvm::Optional<TweakArgs> tweakArgs;
|
[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 &, ExecuteCommandParams &,
|
|
|
|
llvm::json::Path);
|
[clangd] Handle clangd.applyFix server-side
Summary:
When the user selects a fix-it (or any code action with commands), it is
possible to let the client forward the selected command to the server.
When the clangd.applyFix command is handled on the server, it can send a
workspace/applyEdit request to the client. This has the advantage that
the client doesn't explicitly have to know how to handle
clangd.applyFix. Therefore, the code to handle clangd.applyFix in the VS
Code extension (and any other Clangd client) is not required anymore.
Reviewers: ilya-biryukov, sammccall, Nebiroth, hokein
Reviewed By: hokein
Subscribers: ioeric, hokein, rwols, puremourning, bkramer, ilya-biryukov
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D39276
llvm-svn: 317322
2017-11-03 21:39:15 +08:00
|
|
|
|
2018-02-16 22:15:55 +08:00
|
|
|
struct Command : public ExecuteCommandParams {
|
|
|
|
std::string title;
|
|
|
|
};
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const Command &C);
|
2018-02-16 22:15:55 +08:00
|
|
|
|
2018-10-17 00:29:41 +08:00
|
|
|
/// A code action represents a change that can be performed in code, e.g. to fix
|
|
|
|
/// a problem or to refactor code.
|
|
|
|
///
|
|
|
|
/// A CodeAction must set either `edit` and/or a `command`. If both are
|
|
|
|
/// supplied, the `edit` is applied first, then the `command` is executed.
|
|
|
|
struct CodeAction {
|
|
|
|
/// A short, human-readable, title for this code action.
|
|
|
|
std::string title;
|
|
|
|
|
|
|
|
/// The kind of the code action.
|
|
|
|
/// Used to filter code actions.
|
|
|
|
llvm::Optional<std::string> kind;
|
|
|
|
const static llvm::StringLiteral QUICKFIX_KIND;
|
[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 static llvm::StringLiteral REFACTOR_KIND;
|
2019-06-18 21:37:54 +08:00
|
|
|
const static llvm::StringLiteral INFO_KIND;
|
2018-10-17 00:29:41 +08:00
|
|
|
|
|
|
|
/// The diagnostics that this code action resolves.
|
|
|
|
llvm::Optional<std::vector<Diagnostic>> diagnostics;
|
|
|
|
|
2020-09-29 22:28:50 +08:00
|
|
|
/// Marks this as a preferred action. Preferred actions are used by the
|
|
|
|
/// `auto fix` command and can be targeted by keybindings.
|
|
|
|
/// A quick fix should be marked preferred if it properly addresses the
|
|
|
|
/// underlying error. A refactoring should be marked preferred if it is the
|
|
|
|
/// most reasonable choice of actions to take.
|
|
|
|
bool isPreferred = false;
|
|
|
|
|
2018-10-17 00:29:41 +08:00
|
|
|
/// The workspace edit this code action performs.
|
|
|
|
llvm::Optional<WorkspaceEdit> edit;
|
|
|
|
|
|
|
|
/// A command this code action executes. If a code action provides an edit
|
|
|
|
/// and a command, first the edit is executed and then the command.
|
|
|
|
llvm::Optional<Command> command;
|
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const CodeAction &);
|
|
|
|
|
2018-11-23 23:21:19 +08:00
|
|
|
/// Represents programming constructs like variables, classes, interfaces etc.
|
|
|
|
/// that appear in a document. Document symbols can be hierarchical and they
|
|
|
|
/// have two ranges: one that encloses its definition and one that points to its
|
|
|
|
/// most interesting range, e.g. the range of an identifier.
|
|
|
|
struct DocumentSymbol {
|
|
|
|
/// The name of this symbol.
|
|
|
|
std::string name;
|
|
|
|
|
|
|
|
/// More detail for this symbol, e.g the signature of a function.
|
|
|
|
std::string detail;
|
|
|
|
|
|
|
|
/// The kind of this symbol.
|
|
|
|
SymbolKind kind;
|
|
|
|
|
|
|
|
/// Indicates if this symbol is deprecated.
|
|
|
|
bool deprecated;
|
|
|
|
|
|
|
|
/// The range enclosing this symbol not including leading/trailing whitespace
|
|
|
|
/// but everything else like comments. This information is typically used to
|
|
|
|
/// determine if the clients cursor is inside the symbol to reveal in the
|
|
|
|
/// symbol in the UI.
|
|
|
|
Range range;
|
|
|
|
|
|
|
|
/// The range that should be selected and revealed when this symbol is being
|
|
|
|
/// picked, e.g the name of a function. Must be contained by the `range`.
|
|
|
|
Range selectionRange;
|
|
|
|
|
|
|
|
/// Children of this symbol, e.g. properties of a class.
|
|
|
|
std::vector<DocumentSymbol> children;
|
|
|
|
};
|
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &O, const DocumentSymbol &S);
|
|
|
|
llvm::json::Value toJSON(const DocumentSymbol &S);
|
|
|
|
|
[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
|
|
|
/// Represents information about programming constructs like variables, classes,
|
|
|
|
/// interfaces etc.
|
|
|
|
struct SymbolInformation {
|
|
|
|
/// The name of this symbol.
|
|
|
|
std::string name;
|
|
|
|
|
|
|
|
/// The kind of this symbol.
|
|
|
|
SymbolKind kind;
|
|
|
|
|
|
|
|
/// The location of this symbol.
|
|
|
|
Location location;
|
|
|
|
|
|
|
|
/// The name of the symbol containing this symbol.
|
|
|
|
std::string containerName;
|
2020-10-06 03:41:35 +08:00
|
|
|
|
|
|
|
/// The score that clangd calculates to rank the returned symbols.
|
|
|
|
/// This excludes the fuzzy-matching score between `name` and the query.
|
|
|
|
/// (Specifically, the last ::-separated component).
|
|
|
|
/// This can be used to re-rank results as the user types, using client-side
|
|
|
|
/// fuzzy-matching (that score should be multiplied with this one).
|
|
|
|
/// This is a clangd extension, set only for workspace/symbol responses.
|
|
|
|
llvm::Optional<float> score;
|
[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
|
|
|
};
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const SymbolInformation &);
|
[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
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &, const SymbolInformation &);
|
|
|
|
|
2018-11-28 00:40:46 +08:00
|
|
|
/// Represents information about identifier.
|
|
|
|
/// This is returned from textDocument/symbolInfo, which is a clangd extension.
|
|
|
|
struct SymbolDetails {
|
|
|
|
std::string name;
|
|
|
|
|
|
|
|
std::string containerName;
|
|
|
|
|
|
|
|
/// Unified Symbol Resolution identifier
|
|
|
|
/// This is an opaque string uniquely identifying a symbol.
|
|
|
|
/// Unlike SymbolID, it is variable-length and somewhat human-readable.
|
|
|
|
/// It is a common representation across several clang tools.
|
|
|
|
/// (See USRGeneration.h)
|
|
|
|
std::string USR;
|
|
|
|
|
2020-10-29 23:04:53 +08:00
|
|
|
SymbolID ID;
|
2018-11-28 00:40:46 +08:00
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const SymbolDetails &);
|
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &, const SymbolDetails &);
|
|
|
|
bool operator==(const SymbolDetails &, const SymbolDetails &);
|
|
|
|
|
[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
|
|
|
/// The parameters of a Workspace Symbol Request.
|
|
|
|
struct WorkspaceSymbolParams {
|
|
|
|
/// A non-empty query string
|
|
|
|
std::string query;
|
|
|
|
};
|
[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 &, WorkspaceSymbolParams &,
|
|
|
|
llvm::json::Path);
|
[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
|
|
|
|
[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
|
|
|
struct ApplyWorkspaceEditParams {
|
|
|
|
WorkspaceEdit edit;
|
|
|
|
};
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const ApplyWorkspaceEditParams &);
|
[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-08-05 20:48:09 +08:00
|
|
|
struct ApplyWorkspaceEditResponse {
|
|
|
|
bool applied = true;
|
|
|
|
llvm::Optional<std::string> failureReason;
|
|
|
|
};
|
[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 &, ApplyWorkspaceEditResponse &,
|
|
|
|
llvm::json::Path);
|
2019-08-05 20:48:09 +08:00
|
|
|
|
2017-04-04 17:46:39 +08:00
|
|
|
struct TextDocumentPositionParams {
|
|
|
|
/// The text document.
|
|
|
|
TextDocumentIdentifier textDocument;
|
|
|
|
|
|
|
|
/// The position inside the text document.
|
|
|
|
Position position;
|
|
|
|
};
|
[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 &, TextDocumentPositionParams &,
|
|
|
|
llvm::json::Path);
|
2017-04-04 17:46:39 +08:00
|
|
|
|
2019-01-03 21:37:12 +08:00
|
|
|
enum class CompletionTriggerKind {
|
|
|
|
/// Completion was triggered by typing an identifier (24x7 code
|
|
|
|
/// complete), manual invocation (e.g Ctrl+Space) or via API.
|
|
|
|
Invoked = 1,
|
|
|
|
/// Completion was triggered by a trigger character specified by
|
|
|
|
/// the `triggerCharacters` properties of the `CompletionRegistrationOptions`.
|
|
|
|
TriggerCharacter = 2,
|
|
|
|
/// Completion was re-triggered as the current completion list is incomplete.
|
|
|
|
TriggerTriggerForIncompleteCompletions = 3
|
|
|
|
};
|
|
|
|
|
|
|
|
struct CompletionContext {
|
|
|
|
/// How the completion was triggered.
|
|
|
|
CompletionTriggerKind triggerKind = CompletionTriggerKind::Invoked;
|
|
|
|
/// The trigger character (a single character) that has trigger code complete.
|
|
|
|
/// Is undefined if `triggerKind !== CompletionTriggerKind.TriggerCharacter`
|
|
|
|
std::string triggerCharacter;
|
|
|
|
};
|
[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 &, CompletionContext &, llvm::json::Path);
|
2019-01-03 21:37:12 +08:00
|
|
|
|
|
|
|
struct CompletionParams : TextDocumentPositionParams {
|
|
|
|
CompletionContext 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 &, CompletionParams &, llvm::json::Path);
|
2019-01-03 21:37:12 +08:00
|
|
|
|
[clangd] Implement textDocument/hover
Summary: Implemention of textDocument/hover as described in LSP definition.
This patch adds a basic Hover implementation. When hovering a variable,
function, method or namespace, clangd will return a text containing the
declaration's scope, as well as the declaration of the hovered entity.
For example, for a variable:
Declared in class Foo::Bar
int hello = 2
For macros, the macro definition is returned.
This patch doesn't include:
- markdown support (the client I use doesn't support it yet)
- range support (optional in the Hover response)
- comments associated to variables/functions/classes
They are kept as future work to keep this patch simpler.
I added tests in XRefsTests.cpp. hover.test contains one simple
smoketest to make sure the feature works from a black box perspective.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: sammccall, mgrang, klimek, rwols, ilya-biryukov, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D35894
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325395
2018-02-17 05:38:15 +08:00
|
|
|
struct MarkupContent {
|
2018-02-17 07:12:26 +08:00
|
|
|
MarkupKind kind = MarkupKind::PlainText;
|
|
|
|
std::string value;
|
[clangd] Implement textDocument/hover
Summary: Implemention of textDocument/hover as described in LSP definition.
This patch adds a basic Hover implementation. When hovering a variable,
function, method or namespace, clangd will return a text containing the
declaration's scope, as well as the declaration of the hovered entity.
For example, for a variable:
Declared in class Foo::Bar
int hello = 2
For macros, the macro definition is returned.
This patch doesn't include:
- markdown support (the client I use doesn't support it yet)
- range support (optional in the Hover response)
- comments associated to variables/functions/classes
They are kept as future work to keep this patch simpler.
I added tests in XRefsTests.cpp. hover.test contains one simple
smoketest to make sure the feature works from a black box perspective.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Subscribers: sammccall, mgrang, klimek, rwols, ilya-biryukov, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D35894
Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
Signed-off-by: William Enright <william.enright@polymtl.ca>
llvm-svn: 325395
2018-02-17 05:38:15 +08:00
|
|
|
};
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const MarkupContent &MC);
|
[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
|
|
|
|
|
|
|
struct Hover {
|
|
|
|
/// The hover's content
|
2018-02-17 07:12:26 +08:00
|
|
|
MarkupContent 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
|
|
|
|
|
|
|
/// An optional range is a range inside a text document
|
|
|
|
/// that is used to visualize a hover, e.g. by changing the background color.
|
2018-02-17 07:12:26 +08:00
|
|
|
llvm::Optional<Range> 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
|
|
|
};
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const Hover &H);
|
[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
|
|
|
|
2017-04-04 17:46:39 +08:00
|
|
|
/// Defines whether the insert text in a completion item should be interpreted
|
|
|
|
/// as plain text or a snippet.
|
|
|
|
enum class InsertTextFormat {
|
|
|
|
Missing = 0,
|
|
|
|
/// The primary text to be inserted is treated as a plain string.
|
|
|
|
PlainText = 1,
|
|
|
|
/// The primary text to be inserted is treated as a snippet.
|
|
|
|
///
|
|
|
|
/// A snippet can define tab stops and placeholders with `$1`, `$2`
|
|
|
|
/// and `${3:foo}`. `$0` defines the final tab stop, it defaults to the end
|
|
|
|
/// of the snippet. Placeholders with equal identifiers are linked, that is
|
|
|
|
/// typing in one will update others too.
|
|
|
|
///
|
|
|
|
/// See also:
|
|
|
|
/// https//github.com/Microsoft/vscode/blob/master/src/vs/editor/contrib/snippet/common/snippet.md
|
|
|
|
Snippet = 2,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct CompletionItem {
|
|
|
|
/// The label of this completion item. By default also the text that is
|
|
|
|
/// inserted when selecting this completion.
|
|
|
|
std::string label;
|
|
|
|
|
|
|
|
/// The kind of this completion item. Based of the kind an icon is chosen by
|
|
|
|
/// the editor.
|
|
|
|
CompletionItemKind kind = CompletionItemKind::Missing;
|
|
|
|
|
|
|
|
/// A human-readable string with additional information about this item, like
|
|
|
|
/// type or symbol information.
|
|
|
|
std::string detail;
|
|
|
|
|
|
|
|
/// A human-readable string that represents a doc-comment.
|
2020-04-30 16:49:32 +08:00
|
|
|
llvm::Optional<MarkupContent> documentation;
|
2017-04-04 17:46:39 +08:00
|
|
|
|
|
|
|
/// A string that should be used when comparing this item with other items.
|
|
|
|
/// When `falsy` the label is used.
|
|
|
|
std::string sortText;
|
|
|
|
|
|
|
|
/// A string that should be used when filtering a set of completion items.
|
|
|
|
/// When `falsy` the label is used.
|
|
|
|
std::string filterText;
|
|
|
|
|
|
|
|
/// A string that should be inserted to a document when selecting this
|
|
|
|
/// completion. When `falsy` the label is used.
|
|
|
|
std::string insertText;
|
|
|
|
|
|
|
|
/// The format of the insert text. The format applies to both the `insertText`
|
|
|
|
/// property and the `newText` property of a provided `textEdit`.
|
|
|
|
InsertTextFormat insertTextFormat = InsertTextFormat::Missing;
|
|
|
|
|
|
|
|
/// An edit which is applied to a document when selecting this completion.
|
|
|
|
/// When an edit is provided `insertText` is ignored.
|
|
|
|
///
|
|
|
|
/// Note: The range of the edit must be a single line range and it must
|
|
|
|
/// contain the position at which completion has been requested.
|
|
|
|
llvm::Optional<TextEdit> textEdit;
|
|
|
|
|
|
|
|
/// An optional array of additional text edits that are applied when selecting
|
|
|
|
/// this completion. Edits must not overlap with the main edit nor with
|
|
|
|
/// themselves.
|
|
|
|
std::vector<TextEdit> additionalTextEdits;
|
2017-04-07 19:03:26 +08:00
|
|
|
|
2018-09-07 02:52:26 +08:00
|
|
|
/// Indicates if this item is deprecated.
|
|
|
|
bool deprecated = false;
|
|
|
|
|
2020-10-06 03:41:35 +08:00
|
|
|
/// The score that clangd calculates to rank the returned completions.
|
|
|
|
/// This excludes the fuzzy-match between `filterText` and the partial word.
|
|
|
|
/// This can be used to re-rank results as the user types, using client-side
|
|
|
|
/// fuzzy-matching (that score should be multiplied with this one).
|
|
|
|
/// This is a clangd extension.
|
2020-02-13 21:17:30 +08:00
|
|
|
float score = 0.f;
|
|
|
|
|
2020-02-19 00:55:12 +08:00
|
|
|
// TODO: Add custom commitCharacters for some of the completion items. For
|
|
|
|
// example, it makes sense to use () only for the functions.
|
2017-04-04 17:46:39 +08:00
|
|
|
// TODO(krasimir): The following optional fields defined by the language
|
|
|
|
// server protocol are unsupported:
|
|
|
|
//
|
|
|
|
// data?: any - A data entry field that is preserved on a completion item
|
|
|
|
// between a completion and a completion resolve request.
|
|
|
|
};
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const CompletionItem &);
|
[clangd] Use operator<< to prevent printers issues in Gtest
Summary:
It is possible that there will be two different instantiations of
the printer template for a given type and some tests could end up calling the
wrong (default) one. For example, it was seen in CodeCompleteTests.cpp when
printing CompletionItems that it would use the wrong printer because the default
is also instantiated in ClangdTests.cpp.
With this change, objects that were previously printed with a custom Printer now
get printed through the operator<< which is declared alongside the class.
This rule of the thumb should make it less error-prone.
Reviewers: simark, ilya-biryukov, sammccall
Reviewed By: simark, ilya-biryukov, sammccall
Subscribers: bkramer, hokein, sammccall, klimek, ilya-biryukov, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44764
llvm-svn: 329725
2018-04-11 01:34:46 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &, const CompletionItem &);
|
2017-04-04 17:46:39 +08:00
|
|
|
|
2017-11-08 15:44:12 +08:00
|
|
|
bool operator<(const CompletionItem &, const CompletionItem &);
|
|
|
|
|
2017-11-15 17:16:29 +08:00
|
|
|
/// Represents a collection of completion items to be presented in the editor.
|
|
|
|
struct CompletionList {
|
|
|
|
/// The list is not complete. Further typing should result in recomputing the
|
|
|
|
/// list.
|
|
|
|
bool isIncomplete = false;
|
|
|
|
|
|
|
|
/// The completion items.
|
|
|
|
std::vector<CompletionItem> items;
|
|
|
|
};
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const CompletionList &);
|
2017-11-15 17:16:29 +08:00
|
|
|
|
2017-10-06 19:54:17 +08:00
|
|
|
/// A single parameter of a particular signature.
|
|
|
|
struct ParameterInformation {
|
|
|
|
|
2019-06-04 17:36:59 +08:00
|
|
|
/// The label of this parameter. Ignored when labelOffsets is set.
|
|
|
|
std::string labelString;
|
|
|
|
|
|
|
|
/// Inclusive start and exclusive end offsets withing the containing signature
|
|
|
|
/// label.
|
|
|
|
/// Offsets are computed by lspLength(), which counts UTF-16 code units by
|
|
|
|
/// default but that can be overriden, see its documentation for details.
|
|
|
|
llvm::Optional<std::pair<unsigned, unsigned>> labelOffsets;
|
2017-10-06 19:54:17 +08:00
|
|
|
|
|
|
|
/// The documentation of this parameter. Optional.
|
|
|
|
std::string documentation;
|
|
|
|
};
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const ParameterInformation &);
|
2017-10-06 19:54:17 +08:00
|
|
|
|
|
|
|
/// Represents the signature of something callable.
|
|
|
|
struct SignatureInformation {
|
|
|
|
|
|
|
|
/// The label of this signature. Mandatory.
|
|
|
|
std::string label;
|
|
|
|
|
|
|
|
/// The documentation of this signature. Optional.
|
|
|
|
std::string documentation;
|
|
|
|
|
|
|
|
/// The parameters of this signature.
|
|
|
|
std::vector<ParameterInformation> parameters;
|
|
|
|
};
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const SignatureInformation &);
|
[clangd] Use operator<< to prevent printers issues in Gtest
Summary:
It is possible that there will be two different instantiations of
the printer template for a given type and some tests could end up calling the
wrong (default) one. For example, it was seen in CodeCompleteTests.cpp when
printing CompletionItems that it would use the wrong printer because the default
is also instantiated in ClangdTests.cpp.
With this change, objects that were previously printed with a custom Printer now
get printed through the operator<< which is declared alongside the class.
This rule of the thumb should make it less error-prone.
Reviewers: simark, ilya-biryukov, sammccall
Reviewed By: simark, ilya-biryukov, sammccall
Subscribers: bkramer, hokein, sammccall, klimek, ilya-biryukov, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44764
llvm-svn: 329725
2018-04-11 01:34:46 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &,
|
|
|
|
const SignatureInformation &);
|
2017-10-06 19:54:17 +08:00
|
|
|
|
|
|
|
/// Represents the signature of a callable.
|
|
|
|
struct SignatureHelp {
|
|
|
|
|
|
|
|
/// The resulting signatures.
|
|
|
|
std::vector<SignatureInformation> signatures;
|
|
|
|
|
|
|
|
/// The active signature.
|
|
|
|
int activeSignature = 0;
|
|
|
|
|
|
|
|
/// The active parameter of the active signature.
|
|
|
|
int activeParameter = 0;
|
2018-08-30 21:14:31 +08:00
|
|
|
|
|
|
|
/// Position of the start of the argument list, including opening paren. e.g.
|
|
|
|
/// foo("first arg", "second arg",
|
|
|
|
/// ^-argListStart ^-cursor
|
|
|
|
/// This is a clangd-specific extension, it is only available via C++ API and
|
|
|
|
/// not currently serialized for the LSP.
|
|
|
|
Position argListStart;
|
2017-10-06 19:54:17 +08:00
|
|
|
};
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const SignatureHelp &);
|
2017-10-06 19:54:17 +08:00
|
|
|
|
2017-11-09 19:30:04 +08:00
|
|
|
struct RenameParams {
|
|
|
|
/// The document that was opened.
|
|
|
|
TextDocumentIdentifier textDocument;
|
|
|
|
|
|
|
|
/// The position at which this request was sent.
|
|
|
|
Position position;
|
|
|
|
|
|
|
|
/// The new name of the symbol.
|
|
|
|
std::string newName;
|
|
|
|
};
|
[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 &, RenameParams &, llvm::json::Path);
|
2017-11-09 19:30:04 +08:00
|
|
|
|
[clangd] Document highlights for clangd
Summary: Implementation of Document Highlights Request as described in
LSP.
Contributed by William Enright (nebiroth).
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Reviewed By: malaperle
Subscribers: mgrang, sammccall, klimek, ioeric, rwols, cfe-commits, arphaman, ilya-biryukov
Differential Revision: https://reviews.llvm.org/D38425
llvm-svn: 320474
2017-12-12 20:27:47 +08:00
|
|
|
enum class DocumentHighlightKind { Text = 1, Read = 2, Write = 3 };
|
|
|
|
|
|
|
|
/// A document highlight is a range inside a text document which deserves
|
|
|
|
/// special attention. Usually a document highlight is visualized by changing
|
|
|
|
/// the background color of its range.
|
|
|
|
|
|
|
|
struct DocumentHighlight {
|
|
|
|
/// The range this highlight applies to.
|
|
|
|
Range range;
|
|
|
|
|
|
|
|
/// The highlight kind, default is DocumentHighlightKind.Text.
|
|
|
|
DocumentHighlightKind kind = DocumentHighlightKind::Text;
|
|
|
|
|
|
|
|
friend bool operator<(const DocumentHighlight &LHS,
|
|
|
|
const DocumentHighlight &RHS) {
|
|
|
|
int LHSKind = static_cast<int>(LHS.kind);
|
|
|
|
int RHSKind = static_cast<int>(RHS.kind);
|
|
|
|
return std::tie(LHS.range, LHSKind) < std::tie(RHS.range, RHSKind);
|
|
|
|
}
|
|
|
|
|
|
|
|
friend bool operator==(const DocumentHighlight &LHS,
|
|
|
|
const DocumentHighlight &RHS) {
|
|
|
|
return LHS.kind == RHS.kind && LHS.range == RHS.range;
|
|
|
|
}
|
|
|
|
};
|
2018-07-09 22:25:59 +08:00
|
|
|
llvm::json::Value toJSON(const DocumentHighlight &DH);
|
[clangd] Use operator<< to prevent printers issues in Gtest
Summary:
It is possible that there will be two different instantiations of
the printer template for a given type and some tests could end up calling the
wrong (default) one. For example, it was seen in CodeCompleteTests.cpp when
printing CompletionItems that it would use the wrong printer because the default
is also instantiated in ClangdTests.cpp.
With this change, objects that were previously printed with a custom Printer now
get printed through the operator<< which is declared alongside the class.
This rule of the thumb should make it less error-prone.
Reviewers: simark, ilya-biryukov, sammccall
Reviewed By: simark, ilya-biryukov, sammccall
Subscribers: bkramer, hokein, sammccall, klimek, ilya-biryukov, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44764
llvm-svn: 329725
2018-04-11 01:34:46 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &, const DocumentHighlight &);
|
[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
|
|
|
|
[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
|
|
|
enum class TypeHierarchyDirection { Children = 0, Parents = 1, Both = 2 };
|
[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);
|
[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
|
|
|
|
|
|
|
/// The type hierarchy params is an extension of the
|
|
|
|
/// `TextDocumentPositionsParams` with optional properties which can be used to
|
|
|
|
/// eagerly resolve the item when requesting from the server.
|
|
|
|
struct TypeHierarchyParams : public TextDocumentPositionParams {
|
|
|
|
/// The hierarchy levels to resolve. `0` indicates no level.
|
|
|
|
int resolve = 0;
|
|
|
|
|
|
|
|
/// The direction of the hierarchy levels to resolve.
|
|
|
|
TypeHierarchyDirection direction = TypeHierarchyDirection::Parents;
|
|
|
|
};
|
[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 &, TypeHierarchyParams &,
|
|
|
|
llvm::json::Path);
|
[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
|
|
|
|
|
|
|
struct TypeHierarchyItem {
|
|
|
|
/// The human readable name of the hierarchy item.
|
|
|
|
std::string name;
|
|
|
|
|
|
|
|
/// Optional detail for the hierarchy item. It can be, for instance, the
|
|
|
|
/// signature of a function or method.
|
|
|
|
llvm::Optional<std::string> detail;
|
|
|
|
|
|
|
|
/// The kind of the hierarchy item. For instance, class or interface.
|
|
|
|
SymbolKind kind;
|
|
|
|
|
|
|
|
/// `true` if the hierarchy item is deprecated. Otherwise, `false`.
|
2019-07-13 11:24:48 +08:00
|
|
|
bool deprecated = false;
|
[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
|
|
|
|
|
|
|
/// The URI of the text document where this type hierarchy item belongs to.
|
|
|
|
URIForFile uri;
|
|
|
|
|
|
|
|
/// The range enclosing this type hierarchy item not including
|
|
|
|
/// leading/trailing whitespace but everything else like comments. This
|
|
|
|
/// information is typically used to determine if the client's cursor is
|
|
|
|
/// inside the type hierarch item to reveal in the symbol in the UI.
|
|
|
|
Range range;
|
|
|
|
|
|
|
|
/// The range that should be selected and revealed when this type hierarchy
|
|
|
|
/// item is being picked, e.g. the name of a function. Must be contained by
|
|
|
|
/// the `range`.
|
|
|
|
Range selectionRange;
|
|
|
|
|
|
|
|
/// If this type hierarchy item is resolved, it contains the direct parents.
|
|
|
|
/// Could be empty if the item does not have direct parents. If not defined,
|
|
|
|
/// the parents have not been resolved yet.
|
|
|
|
llvm::Optional<std::vector<TypeHierarchyItem>> parents;
|
|
|
|
|
|
|
|
/// If this type hierarchy item is resolved, it contains the direct children
|
|
|
|
/// of the current item. Could be empty if the item does not have any
|
|
|
|
/// descendants. If not defined, the children have not been resolved.
|
|
|
|
llvm::Optional<std::vector<TypeHierarchyItem>> children;
|
|
|
|
|
2020-11-10 13:20:38 +08:00
|
|
|
/// An optional 'data' field, which can be used to identify a type hierarchy
|
2019-07-13 11:24:48 +08:00
|
|
|
/// item in a resolve request.
|
|
|
|
llvm::Optional<std::string> 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
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const TypeHierarchyItem &);
|
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &, const TypeHierarchyItem &);
|
[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 &, TypeHierarchyItem &, llvm::json::Path);
|
2019-07-13 11:24:48 +08:00
|
|
|
|
|
|
|
/// Parameters for the `typeHierarchy/resolve` request.
|
|
|
|
struct ResolveTypeHierarchyItemParams {
|
|
|
|
/// The item to resolve.
|
|
|
|
TypeHierarchyItem item;
|
|
|
|
|
|
|
|
/// The hierarchy levels to resolve. `0` indicates no level.
|
|
|
|
int resolve;
|
|
|
|
|
|
|
|
/// The direction of the hierarchy levels to resolve.
|
|
|
|
TypeHierarchyDirection direction;
|
|
|
|
};
|
[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 &, ResolveTypeHierarchyItemParams &,
|
|
|
|
llvm::json::Path);
|
[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
|
|
|
|
2020-11-10 13:20:38 +08:00
|
|
|
enum class SymbolTag { Deprecated = 1 };
|
|
|
|
llvm::json::Value toJSON(SymbolTag);
|
|
|
|
|
|
|
|
/// The parameter of a `textDocument/prepareCallHierarchy` request.
|
|
|
|
struct CallHierarchyPrepareParams : public TextDocumentPositionParams {};
|
|
|
|
|
|
|
|
/// Represents programming constructs like functions or constructors
|
|
|
|
/// in the context of call hierarchy.
|
|
|
|
struct CallHierarchyItem {
|
|
|
|
/// The name of this item.
|
|
|
|
std::string name;
|
|
|
|
|
|
|
|
/// The kind of this item.
|
|
|
|
SymbolKind kind;
|
|
|
|
|
|
|
|
/// Tags for this item.
|
|
|
|
std::vector<SymbolTag> tags;
|
|
|
|
|
|
|
|
/// More detaill for this item, e.g. the signature of a function.
|
|
|
|
std::string detail;
|
|
|
|
|
|
|
|
/// The resource identifier of this item.
|
|
|
|
URIForFile uri;
|
|
|
|
|
|
|
|
/// The range enclosing this symbol not including leading / trailing
|
|
|
|
/// whitespace but everything else, e.g. comments and code.
|
|
|
|
Range range;
|
|
|
|
|
|
|
|
/// The range that should be selected and revealed when this symbol
|
|
|
|
/// is being picked, e.g. the name of a function.
|
|
|
|
/// Must be contained by `Rng`.
|
|
|
|
Range selectionRange;
|
|
|
|
|
|
|
|
/// An optional 'data' field, which can be used to identify a call
|
|
|
|
/// hierarchy item in an incomingCalls or outgoingCalls request.
|
|
|
|
std::string data;
|
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const CallHierarchyItem &);
|
|
|
|
bool fromJSON(const llvm::json::Value &, CallHierarchyItem &, llvm::json::Path);
|
|
|
|
|
|
|
|
/// The parameter of a `callHierarchy/incomingCalls` request.
|
|
|
|
struct CallHierarchyIncomingCallsParams {
|
|
|
|
CallHierarchyItem item;
|
|
|
|
};
|
|
|
|
bool fromJSON(const llvm::json::Value &, CallHierarchyIncomingCallsParams &,
|
|
|
|
llvm::json::Path);
|
|
|
|
|
|
|
|
/// Represents an incoming call, e.g. a caller of a method or constructor.
|
|
|
|
struct CallHierarchyIncomingCall {
|
|
|
|
/// The item that makes the call.
|
|
|
|
CallHierarchyItem from;
|
|
|
|
|
|
|
|
/// The range at which the calls appear.
|
|
|
|
/// This is relative to the caller denoted by `From`.
|
|
|
|
std::vector<Range> fromRanges;
|
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const CallHierarchyIncomingCall &);
|
|
|
|
|
|
|
|
/// The parameter of a `callHierarchy/outgoingCalls` request.
|
|
|
|
struct CallHierarchyOutgoingCallsParams {
|
|
|
|
CallHierarchyItem item;
|
|
|
|
};
|
|
|
|
bool fromJSON(const llvm::json::Value &, CallHierarchyOutgoingCallsParams &,
|
|
|
|
llvm::json::Path);
|
|
|
|
|
|
|
|
/// Represents an outgoing call, e.g. calling a getter from a method or
|
|
|
|
/// a method from a constructor etc.
|
|
|
|
struct CallHierarchyOutgoingCall {
|
|
|
|
/// The item that is called.
|
|
|
|
CallHierarchyItem to;
|
|
|
|
|
|
|
|
/// The range at which this item is called.
|
|
|
|
/// This is the range relative to the caller, and not `To`.
|
|
|
|
std::vector<Range> fromRanges;
|
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const CallHierarchyOutgoingCall &);
|
|
|
|
|
2018-09-05 19:53:07 +08:00
|
|
|
struct ReferenceParams : public TextDocumentPositionParams {
|
|
|
|
// For now, no options like context.includeDeclaration are supported.
|
|
|
|
};
|
[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 &, ReferenceParams &, llvm::json::Path);
|
2018-09-05 19:53:07 +08:00
|
|
|
|
2018-12-20 23:39:12 +08:00
|
|
|
/// Clangd extension: indicates the current state of the file in clangd,
|
|
|
|
/// sent from server via the `textDocument/clangd.fileStatus` notification.
|
|
|
|
struct FileStatus {
|
|
|
|
/// The text document's URI.
|
|
|
|
URIForFile uri;
|
|
|
|
/// The human-readable string presents the current state of the file, can be
|
|
|
|
/// shown in the UI (e.g. status bar).
|
|
|
|
std::string state;
|
|
|
|
// FIXME: add detail messages.
|
|
|
|
};
|
2020-03-24 09:24:47 +08:00
|
|
|
llvm::json::Value toJSON(const FileStatus &);
|
|
|
|
|
|
|
|
/// Specifies a single semantic token in the document.
|
|
|
|
/// This struct is not part of LSP, which just encodes lists of tokens as
|
|
|
|
/// arrays of numbers directly.
|
|
|
|
struct SemanticToken {
|
|
|
|
/// token line number, relative to the previous token
|
|
|
|
unsigned deltaLine = 0;
|
|
|
|
/// token start character, relative to the previous token
|
|
|
|
/// (relative to 0 or the previous token's start if they are on the same line)
|
|
|
|
unsigned deltaStart = 0;
|
|
|
|
/// the length of the token. A token cannot be multiline
|
|
|
|
unsigned length = 0;
|
|
|
|
/// will be looked up in `SemanticTokensLegend.tokenTypes`
|
|
|
|
unsigned tokenType = 0;
|
|
|
|
/// each set bit will be looked up in `SemanticTokensLegend.tokenModifiers`
|
|
|
|
unsigned tokenModifiers = 0;
|
|
|
|
};
|
[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 &, const SemanticToken &);
|
2020-03-24 09:24:47 +08:00
|
|
|
|
|
|
|
/// A versioned set of tokens.
|
|
|
|
struct SemanticTokens {
|
|
|
|
// An optional result id. If provided and clients support delta updating
|
|
|
|
// the client will include the result id in the next semantic token request.
|
|
|
|
// A server can then instead of computing all semantic tokens again simply
|
|
|
|
// send a delta.
|
[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
|
|
|
std::string resultId;
|
2020-03-24 09:24:47 +08:00
|
|
|
|
2020-07-10 22:08:14 +08:00
|
|
|
/// The actual tokens.
|
|
|
|
std::vector<SemanticToken> tokens; // encoded as a flat integer array.
|
2020-03-24 09:24:47 +08:00
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const SemanticTokens &);
|
|
|
|
|
2020-07-10 22:08:14 +08:00
|
|
|
/// Body of textDocument/semanticTokens/full request.
|
2020-03-24 09:24:47 +08:00
|
|
|
struct SemanticTokensParams {
|
|
|
|
/// The text document.
|
|
|
|
TextDocumentIdentifier 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 &, SemanticTokensParams &,
|
|
|
|
llvm::json::Path);
|
2018-12-20 23:39:12 +08:00
|
|
|
|
2020-07-10 22:08:14 +08:00
|
|
|
/// Body of textDocument/semanticTokens/full/delta request.
|
[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
|
|
|
/// Requests the changes in semantic tokens since a previous response.
|
2020-07-10 22:08:14 +08:00
|
|
|
struct SemanticTokensDeltaParams {
|
[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
|
|
|
/// The text document.
|
|
|
|
TextDocumentIdentifier textDocument;
|
|
|
|
/// The previous result id.
|
|
|
|
std::string previousResultId;
|
|
|
|
};
|
[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);
|
[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
|
|
|
|
|
|
|
/// Describes a a replacement of a contiguous range of semanticTokens.
|
|
|
|
struct SemanticTokensEdit {
|
|
|
|
// LSP specifies `start` and `deleteCount` which are relative to the array
|
|
|
|
// encoding of the previous tokens.
|
|
|
|
// We use token counts instead, and translate when serializing this struct.
|
|
|
|
unsigned startToken = 0;
|
|
|
|
unsigned deleteTokens = 0;
|
2020-07-10 22:08:14 +08:00
|
|
|
std::vector<SemanticToken> tokens; // encoded as a flat integer array
|
[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::Value toJSON(const SemanticTokensEdit &);
|
|
|
|
|
2020-07-10 22:08:14 +08:00
|
|
|
/// This models LSP SemanticTokensDelta | SemanticTokens, which is the result of
|
|
|
|
/// textDocument/semanticTokens/full/delta.
|
|
|
|
struct SemanticTokensOrDelta {
|
[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
|
|
|
std::string resultId;
|
|
|
|
/// Set if we computed edits relative to a previous set of tokens.
|
|
|
|
llvm::Optional<std::vector<SemanticTokensEdit>> edits;
|
|
|
|
/// Set if we computed a fresh set of tokens.
|
2020-07-10 22:08:14 +08:00
|
|
|
llvm::Optional<std::vector<SemanticToken>> tokens; // encoded as integer array
|
[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
|
|
|
};
|
2020-07-10 22:08:14 +08:00
|
|
|
llvm::json::Value toJSON(const SemanticTokensOrDelta &);
|
[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
|
|
|
|
2019-07-04 15:53:12 +08:00
|
|
|
/// Represents a semantic highlighting information that has to be applied on a
|
|
|
|
/// specific line of the text document.
|
2020-03-24 07:31:14 +08:00
|
|
|
struct TheiaSemanticHighlightingInformation {
|
2019-07-04 15:53:12 +08:00
|
|
|
/// The line these highlightings belong to.
|
2019-09-05 23:30:05 +08:00
|
|
|
int Line = 0;
|
2019-07-04 15:53:12 +08:00
|
|
|
/// The base64 encoded string of highlighting tokens.
|
|
|
|
std::string Tokens;
|
2019-09-25 06:17:55 +08:00
|
|
|
/// Is the line in an inactive preprocessor branch?
|
|
|
|
/// This is a clangd extension.
|
|
|
|
/// An inactive line can still contain highlighting tokens as well;
|
|
|
|
/// clients should combine line style and token style if possible.
|
|
|
|
bool IsInactive = false;
|
2019-07-04 15:53:12 +08:00
|
|
|
};
|
2020-03-24 07:31:14 +08:00
|
|
|
bool operator==(const TheiaSemanticHighlightingInformation &Lhs,
|
|
|
|
const TheiaSemanticHighlightingInformation &Rhs);
|
|
|
|
llvm::json::Value
|
|
|
|
toJSON(const TheiaSemanticHighlightingInformation &Highlighting);
|
2019-07-04 15:53:12 +08:00
|
|
|
|
|
|
|
/// Parameters for the semantic highlighting (server-side) push notification.
|
2020-03-24 07:31:14 +08:00
|
|
|
struct TheiaSemanticHighlightingParams {
|
2019-07-04 15:53:12 +08:00
|
|
|
/// The textdocument these highlightings belong to.
|
[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
|
|
|
VersionedTextDocumentIdentifier TextDocument;
|
2019-07-04 15:53:12 +08:00
|
|
|
/// The lines of highlightings that should be sent.
|
2020-03-24 07:31:14 +08:00
|
|
|
std::vector<TheiaSemanticHighlightingInformation> Lines;
|
2019-07-04 15:53:12 +08:00
|
|
|
};
|
2020-03-24 07:31:14 +08:00
|
|
|
llvm::json::Value toJSON(const TheiaSemanticHighlightingParams &Highlighting);
|
2019-07-04 15:53:12 +08:00
|
|
|
|
2019-09-24 21:38:33 +08:00
|
|
|
struct SelectionRangeParams {
|
|
|
|
/// The text document.
|
|
|
|
TextDocumentIdentifier textDocument;
|
|
|
|
|
|
|
|
/// The positions inside the text document.
|
|
|
|
std::vector<Position> positions;
|
|
|
|
};
|
[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 &, SelectionRangeParams &,
|
|
|
|
llvm::json::Path);
|
2019-09-24 21:38:33 +08:00
|
|
|
|
|
|
|
struct SelectionRange {
|
|
|
|
/**
|
|
|
|
* The range of this selection range.
|
|
|
|
*/
|
|
|
|
Range range;
|
|
|
|
/**
|
|
|
|
* The parent selection range containing this range. Therefore `parent.range`
|
|
|
|
* must contain `this.range`.
|
|
|
|
*/
|
|
|
|
std::unique_ptr<SelectionRange> parent;
|
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const SelectionRange &);
|
|
|
|
|
2019-12-17 02:08:51 +08:00
|
|
|
/// Parameters for the document link request.
|
|
|
|
struct DocumentLinkParams {
|
|
|
|
/// The document to provide document links for.
|
|
|
|
TextDocumentIdentifier 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 &, DocumentLinkParams &,
|
|
|
|
llvm::json::Path);
|
2019-12-17 02:08:51 +08:00
|
|
|
|
|
|
|
/// A range in a text document that links to an internal or external resource,
|
|
|
|
/// like another text document or a web site.
|
|
|
|
struct DocumentLink {
|
|
|
|
/// The range this link applies to.
|
|
|
|
Range range;
|
|
|
|
|
|
|
|
/// The uri this link points to. If missing a resolve request is sent later.
|
|
|
|
URIForFile target;
|
|
|
|
|
|
|
|
// TODO(forster): The following optional fields defined by the language
|
|
|
|
// server protocol are unsupported:
|
|
|
|
//
|
|
|
|
// data?: any - A data entry field that is preserved on a document link
|
|
|
|
// between a DocumentLinkRequest and a
|
|
|
|
// DocumentLinkResolveRequest.
|
|
|
|
|
|
|
|
friend bool operator==(const DocumentLink &LHS, const DocumentLink &RHS) {
|
|
|
|
return LHS.range == RHS.range && LHS.target == RHS.target;
|
|
|
|
}
|
|
|
|
|
|
|
|
friend bool operator!=(const DocumentLink &LHS, const DocumentLink &RHS) {
|
|
|
|
return !(LHS == RHS);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const DocumentLink &DocumentLink);
|
|
|
|
|
[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
|
|
|
// FIXME(kirillbobyrev): Add FoldingRangeClientCapabilities so we can support
|
|
|
|
// per-line-folding editors.
|
|
|
|
struct FoldingRangeParams {
|
|
|
|
TextDocumentIdentifier 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 &, FoldingRangeParams &,
|
|
|
|
llvm::json::Path);
|
[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
|
|
|
|
|
|
|
/// Stores information about a region of code that can be folded.
|
|
|
|
struct FoldingRange {
|
|
|
|
unsigned startLine = 0;
|
|
|
|
unsigned startCharacter;
|
|
|
|
unsigned endLine = 0;
|
|
|
|
unsigned endCharacter;
|
|
|
|
llvm::Optional<std::string> kind;
|
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const FoldingRange &Range);
|
|
|
|
|
2020-10-13 06:10:04 +08:00
|
|
|
/// Keys starting with an underscore(_) represent leaves, e.g. _total or _self
|
|
|
|
/// for memory usage of whole subtree or only that specific node in bytes. All
|
|
|
|
/// other keys represents children. An example:
|
|
|
|
/// {
|
|
|
|
/// "_self": 0,
|
|
|
|
/// "_total": 8,
|
|
|
|
/// "child1": {
|
|
|
|
/// "_self": 4,
|
|
|
|
/// "_total": 4,
|
|
|
|
/// }
|
|
|
|
/// "child2": {
|
|
|
|
/// "_self": 2,
|
|
|
|
/// "_total": 4,
|
|
|
|
/// "child_deep": {
|
|
|
|
/// "_self": 2,
|
|
|
|
/// "_total": 2,
|
|
|
|
/// }
|
|
|
|
/// }
|
|
|
|
/// }
|
|
|
|
llvm::json::Value toJSON(const MemoryTree &MT);
|
|
|
|
|
2020-10-17 02:03:48 +08:00
|
|
|
/// Payload for textDocument/ast request.
|
|
|
|
/// This request is a clangd extension.
|
|
|
|
struct ASTParams {
|
|
|
|
/// The text document.
|
|
|
|
TextDocumentIdentifier textDocument;
|
|
|
|
|
|
|
|
/// The position of the node to be dumped.
|
|
|
|
/// The highest-level node that entirely contains the range will be returned.
|
|
|
|
Range range;
|
|
|
|
};
|
|
|
|
bool fromJSON(const llvm::json::Value &, ASTParams &, llvm::json::Path);
|
|
|
|
|
|
|
|
/// Simplified description of a clang AST node.
|
|
|
|
/// This is clangd's internal representation of C++ code.
|
|
|
|
struct ASTNode {
|
|
|
|
/// The general kind of node, such as "expression"
|
|
|
|
/// Corresponds to the base AST node type such as Expr.
|
|
|
|
std::string role;
|
|
|
|
/// The specific kind of node this is, such as "BinaryOperator".
|
|
|
|
/// This is usually a concrete node class (with Expr etc suffix dropped).
|
|
|
|
/// When there's no hierarchy (e.g. TemplateName), the variant (NameKind).
|
|
|
|
std::string kind;
|
|
|
|
/// Brief additional information, such as "||" for the particular operator.
|
|
|
|
/// The information included depends on the node kind, and may be empty.
|
|
|
|
std::string detail;
|
|
|
|
/// A one-line dump of detailed information about the node.
|
|
|
|
/// This includes role/kind/description information, but is rather cryptic.
|
|
|
|
/// It is similar to the output from `clang -Xclang -ast-dump`.
|
|
|
|
/// May be empty for certain types of nodes.
|
|
|
|
std::string arcana;
|
|
|
|
/// The range of the original source file covered by this node.
|
|
|
|
/// May be missing for implicit nodes, or those created by macro expansion.
|
|
|
|
llvm::Optional<Range> range;
|
|
|
|
/// Nodes nested within this one, such as the operands of a BinaryOperator.
|
|
|
|
std::vector<ASTNode> children;
|
|
|
|
};
|
|
|
|
llvm::json::Value toJSON(const ASTNode &);
|
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &, const ASTNode &);
|
|
|
|
|
2017-02-07 18:28:20 +08:00
|
|
|
} // namespace clangd
|
|
|
|
} // namespace clang
|
|
|
|
|
[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
|
|
|
namespace llvm {
|
|
|
|
template <> struct format_provider<clang::clangd::Position> {
|
|
|
|
static void format(const clang::clangd::Position &Pos, raw_ostream &OS,
|
|
|
|
StringRef Style) {
|
|
|
|
assert(Style.empty() && "style modifiers for this type are not supported");
|
|
|
|
OS << Pos;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
} // namespace llvm
|
|
|
|
|
2017-02-07 18:28:20 +08:00
|
|
|
#endif
|