[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
|
|
|
//===--- Tweak.cpp -----------------------------------------------*- C++-*-===//
|
|
|
|
//
|
|
|
|
// 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
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#include "Tweak.h"
|
|
|
|
#include "Logger.h"
|
2019-09-09 20:28:44 +08:00
|
|
|
#include "Path.h"
|
|
|
|
#include "SourceCode.h"
|
2019-10-18 20:57:11 +08:00
|
|
|
#include "index/Index.h"
|
2019-09-09 20:28:44 +08:00
|
|
|
#include "llvm/ADT/None.h"
|
|
|
|
#include "llvm/ADT/Optional.h"
|
[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
|
|
|
#include "llvm/ADT/STLExtras.h"
|
|
|
|
#include "llvm/ADT/StringMap.h"
|
2019-09-09 20:28:44 +08:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
[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
|
|
|
#include "llvm/Support/Error.h"
|
|
|
|
#include "llvm/Support/Registry.h"
|
|
|
|
#include <functional>
|
|
|
|
#include <memory>
|
2019-09-09 20:28:44 +08:00
|
|
|
#include <utility>
|
[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
|
|
|
|
2019-01-30 00:04:39 +08:00
|
|
|
LLVM_INSTANTIATE_REGISTRY(llvm::Registry<clang::clangd::Tweak>)
|
[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
|
|
|
|
|
|
|
namespace clang {
|
|
|
|
namespace clangd {
|
|
|
|
|
|
|
|
/// A handy typedef to save some typing.
|
|
|
|
typedef llvm::Registry<Tweak> TweakRegistry;
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
/// Asserts invariants on TweakRegistry. No-op with assertion disabled.
|
|
|
|
void validateRegistry() {
|
|
|
|
#ifndef NDEBUG
|
|
|
|
llvm::StringSet<> Seen;
|
|
|
|
for (const auto &E : TweakRegistry::entries()) {
|
|
|
|
// REGISTER_TWEAK ensures E.getName() is equal to the tweak class name.
|
|
|
|
// We check that id() matches it.
|
|
|
|
assert(E.instantiate()->id() == E.getName() &&
|
|
|
|
"id should be equal to class name");
|
|
|
|
assert(Seen.try_emplace(E.getName()).second && "duplicate check id");
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
} // namespace
|
|
|
|
|
2019-10-18 20:57:11 +08:00
|
|
|
Tweak::Selection::Selection(const SymbolIndex *Index, ParsedAST &AST,
|
|
|
|
unsigned RangeBegin, unsigned RangeEnd)
|
|
|
|
: Index(Index), AST(AST), SelectionBegin(RangeBegin),
|
|
|
|
SelectionEnd(RangeEnd),
|
[clangd] Ignore semicolons, whitespace, and comments in SelectionTree.
Summary:
Whitespace and comments are a clear bugfix: selecting some
comments/space near a statement doesn't mean you're selecting the
surrounding block.
Semicolons are less obvious, but for similar reasons: these tokens
aren't actually claimed by any AST node (usually), so an AST-based model
like SelectionTree shouldn't take them into account.
Callers may still sometimes care about semis of course:
- when the selection is an expr with a non-expr parent, selection of
the semicolon indicates intent to select the statement.
- when a statement with a trailing semi is selected, we need to know
its range to ensure it can be removed.
SelectionTree may or may not play a role here, but these are separate questions
from its core function of describing which AST nodes were selected.
The mechanism here is the TokenBuffer from syntax-trees. We use it in a
fairly low-level way (just to get boundaries of raw spelled tokens). The
actual mapping of AST nodes to coordinates continues to use the (fairly
mature) SourceLocation based logic. TokenBuffer/Syntax trees
don't currently offer an alternative to getFileRange(), I think.
Reviewers: SureYeaah, kadircet
Subscribers: MaskRay, jkorous, arphaman, cfe-commits, ilya-biryukov
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65486
llvm-svn: 367453
2019-08-01 01:52:40 +08:00
|
|
|
ASTSelection(AST.getASTContext(), AST.getTokens(), RangeBegin, RangeEnd) {
|
2019-05-29 05:52:34 +08:00
|
|
|
auto &SM = AST.getSourceManager();
|
2019-02-01 23:09:47 +08:00
|
|
|
Code = SM.getBufferData(SM.getMainFileID());
|
|
|
|
Cursor = SM.getComposedLoc(SM.getMainFileID(), RangeBegin);
|
|
|
|
}
|
|
|
|
|
2019-07-12 16:50:20 +08:00
|
|
|
std::vector<std::unique_ptr<Tweak>>
|
|
|
|
prepareTweaks(const Tweak::Selection &S,
|
|
|
|
llvm::function_ref<bool(const Tweak &)> Filter) {
|
[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
|
|
|
validateRegistry();
|
|
|
|
|
|
|
|
std::vector<std::unique_ptr<Tweak>> Available;
|
|
|
|
for (const auto &E : TweakRegistry::entries()) {
|
|
|
|
std::unique_ptr<Tweak> T = E.instantiate();
|
2019-07-12 16:50:20 +08:00
|
|
|
if (!Filter(*T) || !T->prepare(S))
|
[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
|
|
|
continue;
|
|
|
|
Available.push_back(std::move(T));
|
|
|
|
}
|
|
|
|
// Ensure deterministic order of the results.
|
|
|
|
llvm::sort(Available,
|
|
|
|
[](const std::unique_ptr<Tweak> &L,
|
|
|
|
const std::unique_ptr<Tweak> &R) { return L->id() < R->id(); });
|
|
|
|
return Available;
|
|
|
|
}
|
|
|
|
|
2019-02-01 13:41:50 +08:00
|
|
|
llvm::Expected<std::unique_ptr<Tweak>> prepareTweak(StringRef ID,
|
[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 Tweak::Selection &S) {
|
|
|
|
auto It = llvm::find_if(
|
|
|
|
TweakRegistry::entries(),
|
|
|
|
[ID](const TweakRegistry::entry &E) { return E.getName() == ID; });
|
|
|
|
if (It == TweakRegistry::end())
|
|
|
|
return llvm::createStringError(llvm::inconvertibleErrorCode(),
|
|
|
|
"id of the tweak is invalid");
|
|
|
|
std::unique_ptr<Tweak> T = It->instantiate();
|
|
|
|
if (!T->prepare(S))
|
|
|
|
return llvm::createStringError(llvm::inconvertibleErrorCode(),
|
|
|
|
"failed to prepare() a check");
|
2019-01-29 23:57:14 +08:00
|
|
|
return std::move(T);
|
[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
|
|
|
}
|
|
|
|
|
2019-09-09 20:28:44 +08:00
|
|
|
llvm::Expected<std::pair<Path, Edit>>
|
|
|
|
Tweak::Effect::fileEdit(const SourceManager &SM, FileID FID,
|
|
|
|
tooling::Replacements Replacements) {
|
|
|
|
Edit Ed(SM.getBufferData(FID), std::move(Replacements));
|
|
|
|
if (auto FilePath = getCanonicalPath(SM.getFileEntryForID(FID), SM))
|
|
|
|
return std::make_pair(*FilePath, std::move(Ed));
|
|
|
|
return llvm::createStringError(
|
|
|
|
llvm::inconvertibleErrorCode(),
|
|
|
|
"Failed to get absolute path for edited file: " +
|
|
|
|
SM.getFileEntryForID(FID)->getName());
|
|
|
|
}
|
|
|
|
|
|
|
|
llvm::Expected<Tweak::Effect>
|
|
|
|
Tweak::Effect::mainFileEdit(const SourceManager &SM,
|
|
|
|
tooling::Replacements Replacements) {
|
|
|
|
auto PathAndEdit = fileEdit(SM, SM.getMainFileID(), std::move(Replacements));
|
|
|
|
if (!PathAndEdit)
|
|
|
|
return PathAndEdit.takeError();
|
|
|
|
Tweak::Effect E;
|
|
|
|
E.ApplyEdits.try_emplace(PathAndEdit->first, PathAndEdit->second);
|
|
|
|
return E;
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
} // namespace clangd
|
|
|
|
} // namespace clang
|