2018-08-15 00:03:32 +08:00
|
|
|
//===--- CodeComplete.cpp ----------------------------------------*- C++-*-===//
|
2017-12-04 21:49:59 +08:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
2018-08-15 00:03:32 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2017-12-04 21:49:59 +08:00
|
|
|
//
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
// Code completion has several moving parts:
|
|
|
|
// - AST-based completions are provided using the completion hooks in Sema.
|
|
|
|
// - external completions are retrieved from the index (using hints from Sema)
|
|
|
|
// - the two sources overlap, and must be merged and overloads bundled
|
|
|
|
// - results must be scored and ranked (see Quality.h) before rendering
|
2017-12-04 21:49:59 +08:00
|
|
|
//
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
// Signature help works in a similar way as code completion, but it is simpler:
|
|
|
|
// it's purely AST-based, and there are few candidates.
|
2017-12-04 21:49:59 +08:00
|
|
|
//
|
2018-08-15 00:03:32 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2017-12-04 21:49:59 +08:00
|
|
|
|
|
|
|
#include "CodeComplete.h"
|
2018-06-22 18:46:59 +08:00
|
|
|
#include "AST.h"
|
2017-12-21 01:24:31 +08:00
|
|
|
#include "CodeCompletionStrings.h"
|
2017-12-04 21:49:59 +08:00
|
|
|
#include "Compiler.h"
|
2018-08-08 16:59:29 +08:00
|
|
|
#include "Diagnostics.h"
|
2018-07-03 16:09:29 +08:00
|
|
|
#include "FileDistance.h"
|
2018-01-13 00:16:09 +08:00
|
|
|
#include "FuzzyMatch.h"
|
2018-05-15 23:29:32 +08:00
|
|
|
#include "Headers.h"
|
2017-12-20 00:50:37 +08:00
|
|
|
#include "Logger.h"
|
[clangd] Extract scoring/ranking logic, and shave yaks.
Summary:
Code completion scoring was embedded in CodeComplete.cpp, which is bad:
- awkward to test. The mechanisms (extracting info from index/sema) can be
unit-tested well, the policy (scoring) should be quantitatively measured.
Neither was easily possible, and debugging was hard.
The intermediate signal struct makes this easier.
- hard to reuse. This is a bug in workspaceSymbols: it just presents the
results in the index order, which is not sorted in practice, it needs to rank
them!
Also, index implementations care about scoring (both query-dependent and
independent) in order to truncate result lists appropriately.
The main yak shaved here is the build() function that had 3 variants across
unit tests is unified in TestTU.h (rather than adding a 4th variant).
Reviewers: ilya-biryukov
Subscribers: klimek, mgorny, ioeric, MaskRay, jkorous, mgrang, cfe-commits
Differential Revision: https://reviews.llvm.org/D46524
llvm-svn: 332378
2018-05-16 01:43:27 +08:00
|
|
|
#include "Quality.h"
|
2018-02-16 22:15:55 +08:00
|
|
|
#include "SourceCode.h"
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
#include "TUScheduler.h"
|
2018-01-31 01:20:54 +08:00
|
|
|
#include "Trace.h"
|
2018-05-15 23:29:32 +08:00
|
|
|
#include "URI.h"
|
2017-12-20 00:50:37 +08:00
|
|
|
#include "index/Index.h"
|
[clangd] Add "member" symbols to the index
Summary:
This adds more symbols to the index:
- member variables and functions
- enum constants in scoped enums
The code completion behavior should remain intact but workspace symbols should
now provide much more useful symbols.
Other symbols should be considered such as the ones in "main files" (files not
being included) but this can be done separately as this introduces its fair
share of problems.
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewers: ioeric, sammccall
Reviewed By: ioeric, sammccall
Subscribers: hokein, sammccall, jkorous, klimek, ilya-biryukov, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44954
llvm-svn: 334017
2018-06-05 22:01:40 +08:00
|
|
|
#include "clang/ASTMatchers/ASTMatchFinder.h"
|
2018-05-16 20:32:49 +08:00
|
|
|
#include "clang/Basic/LangOptions.h"
|
2018-08-13 16:23:01 +08:00
|
|
|
#include "clang/Basic/SourceLocation.h"
|
2018-02-16 22:15:55 +08:00
|
|
|
#include "clang/Format/Format.h"
|
2017-12-04 21:49:59 +08:00
|
|
|
#include "clang/Frontend/CompilerInstance.h"
|
|
|
|
#include "clang/Frontend/FrontendActions.h"
|
2018-01-19 22:34:02 +08:00
|
|
|
#include "clang/Index/USRGeneration.h"
|
2017-12-04 21:49:59 +08:00
|
|
|
#include "clang/Sema/CodeCompleteConsumer.h"
|
|
|
|
#include "clang/Sema/Sema.h"
|
2018-02-16 22:15:55 +08:00
|
|
|
#include "clang/Tooling/Core/Replacement.h"
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
#include "llvm/ADT/Optional.h"
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
#include "llvm/ADT/SmallVector.h"
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
#include "llvm/Support/Error.h"
|
2018-01-10 22:44:34 +08:00
|
|
|
#include "llvm/Support/Format.h"
|
2018-07-05 16:29:33 +08:00
|
|
|
#include "llvm/Support/FormatVariadic.h"
|
2018-07-05 14:20:41 +08:00
|
|
|
#include "llvm/Support/ScopedPrinter.h"
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
#include <algorithm>
|
|
|
|
#include <iterator>
|
2017-12-04 21:49:59 +08:00
|
|
|
#include <queue>
|
|
|
|
|
[clangd] Extract scoring/ranking logic, and shave yaks.
Summary:
Code completion scoring was embedded in CodeComplete.cpp, which is bad:
- awkward to test. The mechanisms (extracting info from index/sema) can be
unit-tested well, the policy (scoring) should be quantitatively measured.
Neither was easily possible, and debugging was hard.
The intermediate signal struct makes this easier.
- hard to reuse. This is a bug in workspaceSymbols: it just presents the
results in the index order, which is not sorted in practice, it needs to rank
them!
Also, index implementations care about scoring (both query-dependent and
independent) in order to truncate result lists appropriately.
The main yak shaved here is the build() function that had 3 variants across
unit tests is unified in TestTU.h (rather than adding a 4th variant).
Reviewers: ilya-biryukov
Subscribers: klimek, mgorny, ioeric, MaskRay, jkorous, mgrang, cfe-commits
Differential Revision: https://reviews.llvm.org/D46524
llvm-svn: 332378
2018-05-16 01:43:27 +08:00
|
|
|
// We log detailed candidate here if you run with -debug-only=codecomplete.
|
2018-06-29 22:47:57 +08:00
|
|
|
#define DEBUG_TYPE "CodeComplete"
|
[clangd] Extract scoring/ranking logic, and shave yaks.
Summary:
Code completion scoring was embedded in CodeComplete.cpp, which is bad:
- awkward to test. The mechanisms (extracting info from index/sema) can be
unit-tested well, the policy (scoring) should be quantitatively measured.
Neither was easily possible, and debugging was hard.
The intermediate signal struct makes this easier.
- hard to reuse. This is a bug in workspaceSymbols: it just presents the
results in the index order, which is not sorted in practice, it needs to rank
them!
Also, index implementations care about scoring (both query-dependent and
independent) in order to truncate result lists appropriately.
The main yak shaved here is the build() function that had 3 variants across
unit tests is unified in TestTU.h (rather than adding a 4th variant).
Reviewers: ilya-biryukov
Subscribers: klimek, mgorny, ioeric, MaskRay, jkorous, mgrang, cfe-commits
Differential Revision: https://reviews.llvm.org/D46524
llvm-svn: 332378
2018-05-16 01:43:27 +08:00
|
|
|
|
2017-12-04 21:49:59 +08:00
|
|
|
namespace clang {
|
|
|
|
namespace clangd {
|
|
|
|
namespace {
|
|
|
|
|
2017-12-20 00:50:37 +08:00
|
|
|
CompletionItemKind toCompletionItemKind(index::SymbolKind Kind) {
|
|
|
|
using SK = index::SymbolKind;
|
|
|
|
switch (Kind) {
|
|
|
|
case SK::Unknown:
|
|
|
|
return CompletionItemKind::Missing;
|
|
|
|
case SK::Module:
|
|
|
|
case SK::Namespace:
|
|
|
|
case SK::NamespaceAlias:
|
|
|
|
return CompletionItemKind::Module;
|
|
|
|
case SK::Macro:
|
|
|
|
return CompletionItemKind::Text;
|
|
|
|
case SK::Enum:
|
|
|
|
return CompletionItemKind::Enum;
|
|
|
|
// FIXME(ioeric): use LSP struct instead of class when it is suppoted in the
|
|
|
|
// protocol.
|
|
|
|
case SK::Struct:
|
|
|
|
case SK::Class:
|
|
|
|
case SK::Protocol:
|
|
|
|
case SK::Extension:
|
|
|
|
case SK::Union:
|
|
|
|
return CompletionItemKind::Class;
|
|
|
|
// FIXME(ioeric): figure out whether reference is the right type for aliases.
|
|
|
|
case SK::TypeAlias:
|
|
|
|
case SK::Using:
|
|
|
|
return CompletionItemKind::Reference;
|
|
|
|
case SK::Function:
|
|
|
|
// FIXME(ioeric): this should probably be an operator. This should be fixed
|
|
|
|
// when `Operator` is support type in the protocol.
|
|
|
|
case SK::ConversionFunction:
|
|
|
|
return CompletionItemKind::Function;
|
|
|
|
case SK::Variable:
|
|
|
|
case SK::Parameter:
|
|
|
|
return CompletionItemKind::Variable;
|
|
|
|
case SK::Field:
|
|
|
|
return CompletionItemKind::Field;
|
|
|
|
// FIXME(ioeric): use LSP enum constant when it is supported in the protocol.
|
|
|
|
case SK::EnumConstant:
|
|
|
|
return CompletionItemKind::Value;
|
|
|
|
case SK::InstanceMethod:
|
|
|
|
case SK::ClassMethod:
|
|
|
|
case SK::StaticMethod:
|
|
|
|
case SK::Destructor:
|
|
|
|
return CompletionItemKind::Method;
|
|
|
|
case SK::InstanceProperty:
|
|
|
|
case SK::ClassProperty:
|
|
|
|
case SK::StaticProperty:
|
|
|
|
return CompletionItemKind::Property;
|
|
|
|
case SK::Constructor:
|
|
|
|
return CompletionItemKind::Constructor;
|
|
|
|
}
|
|
|
|
llvm_unreachable("Unhandled clang::index::SymbolKind.");
|
|
|
|
}
|
|
|
|
|
2018-06-09 05:17:19 +08:00
|
|
|
CompletionItemKind
|
|
|
|
toCompletionItemKind(CodeCompletionResult::ResultKind ResKind,
|
|
|
|
const NamedDecl *Decl) {
|
|
|
|
if (Decl)
|
|
|
|
return toCompletionItemKind(index::getSymbolInfo(Decl).Kind);
|
|
|
|
switch (ResKind) {
|
|
|
|
case CodeCompletionResult::RK_Declaration:
|
|
|
|
llvm_unreachable("RK_Declaration without Decl");
|
|
|
|
case CodeCompletionResult::RK_Keyword:
|
|
|
|
return CompletionItemKind::Keyword;
|
|
|
|
case CodeCompletionResult::RK_Macro:
|
|
|
|
return CompletionItemKind::Text; // unfortunately, there's no 'Macro'
|
|
|
|
// completion items in LSP.
|
|
|
|
case CodeCompletionResult::RK_Pattern:
|
|
|
|
return CompletionItemKind::Snippet;
|
|
|
|
}
|
|
|
|
llvm_unreachable("Unhandled CodeCompletionResult::ResultKind.");
|
|
|
|
}
|
|
|
|
|
2017-12-04 21:49:59 +08:00
|
|
|
/// Get the optional chunk as a string. This function is possibly recursive.
|
|
|
|
///
|
|
|
|
/// The parameter info for each parameter is appended to the Parameters.
|
2018-08-13 16:40:05 +08:00
|
|
|
std::string getOptionalParameters(const CodeCompletionString &CCS,
|
|
|
|
std::vector<ParameterInformation> &Parameters,
|
|
|
|
SignatureQualitySignals &Signal) {
|
2017-12-04 21:49:59 +08:00
|
|
|
std::string Result;
|
|
|
|
for (const auto &Chunk : CCS) {
|
|
|
|
switch (Chunk.Kind) {
|
|
|
|
case CodeCompletionString::CK_Optional:
|
|
|
|
assert(Chunk.Optional &&
|
|
|
|
"Expected the optional code completion string to be non-null.");
|
2018-08-13 16:40:05 +08:00
|
|
|
Result += getOptionalParameters(*Chunk.Optional, Parameters, Signal);
|
2017-12-04 21:49:59 +08:00
|
|
|
break;
|
|
|
|
case CodeCompletionString::CK_VerticalSpace:
|
|
|
|
break;
|
|
|
|
case CodeCompletionString::CK_Placeholder:
|
|
|
|
// A string that acts as a placeholder for, e.g., a function call
|
|
|
|
// argument.
|
|
|
|
// Intentional fallthrough here.
|
|
|
|
case CodeCompletionString::CK_CurrentParameter: {
|
|
|
|
// A piece of text that describes the parameter that corresponds to
|
|
|
|
// the code-completion location within a function call, message send,
|
|
|
|
// macro invocation, etc.
|
|
|
|
Result += Chunk.Text;
|
|
|
|
ParameterInformation Info;
|
|
|
|
Info.label = Chunk.Text;
|
|
|
|
Parameters.push_back(std::move(Info));
|
2018-08-13 16:40:05 +08:00
|
|
|
Signal.ContainsActiveParameter = true;
|
|
|
|
Signal.NumberOfOptionalParameters++;
|
2017-12-04 21:49:59 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
Result += Chunk.Text;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2018-05-15 23:29:32 +08:00
|
|
|
/// Creates a `HeaderFile` from \p Header which can be either a URI or a literal
|
|
|
|
/// include.
|
|
|
|
static llvm::Expected<HeaderFile> toHeaderFile(StringRef Header,
|
|
|
|
llvm::StringRef HintPath) {
|
|
|
|
if (isLiteralInclude(Header))
|
|
|
|
return HeaderFile{Header.str(), /*Verbatim=*/true};
|
|
|
|
auto U = URI::parse(Header);
|
|
|
|
if (!U)
|
|
|
|
return U.takeError();
|
|
|
|
|
|
|
|
auto IncludePath = URI::includeSpelling(*U);
|
|
|
|
if (!IncludePath)
|
|
|
|
return IncludePath.takeError();
|
|
|
|
if (!IncludePath->empty())
|
|
|
|
return HeaderFile{std::move(*IncludePath), /*Verbatim=*/true};
|
|
|
|
|
|
|
|
auto Resolved = URI::resolve(*U, HintPath);
|
|
|
|
if (!Resolved)
|
|
|
|
return Resolved.takeError();
|
|
|
|
return HeaderFile{std::move(*Resolved), /*Verbatim=*/false};
|
|
|
|
}
|
|
|
|
|
2018-08-23 21:14:50 +08:00
|
|
|
// First traverses all method definitions inside current class/struct/union
|
|
|
|
// definition. Than traverses base classes to find virtual methods that haven't
|
|
|
|
// been overriden within current context.
|
|
|
|
// FIXME(kadircet): Currently we cannot see declarations below completion point.
|
|
|
|
// It is because Sema gets run only upto completion point. Need to find a
|
|
|
|
// solution to run it for the whole class/struct/union definition.
|
|
|
|
static std::vector<CodeCompletionResult>
|
|
|
|
getNonOverridenMethodCompletionResults(const DeclContext *DC, Sema *S) {
|
|
|
|
const auto *CR = llvm::dyn_cast<CXXRecordDecl>(DC);
|
|
|
|
// If not inside a class/struct/union return empty.
|
|
|
|
if (!CR)
|
|
|
|
return {};
|
|
|
|
// First store overrides within current class.
|
|
|
|
// These are stored by name to make querying fast in the later step.
|
|
|
|
llvm::StringMap<std::vector<FunctionDecl *>> Overrides;
|
|
|
|
for (auto *Method : CR->methods()) {
|
2018-09-03 23:25:27 +08:00
|
|
|
if (!Method->isVirtual() || !Method->getIdentifier())
|
2018-08-23 21:14:50 +08:00
|
|
|
continue;
|
|
|
|
Overrides[Method->getName()].push_back(Method);
|
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<CodeCompletionResult> Results;
|
|
|
|
for (const auto &Base : CR->bases()) {
|
|
|
|
const auto *BR = Base.getType().getTypePtr()->getAsCXXRecordDecl();
|
|
|
|
if (!BR)
|
|
|
|
continue;
|
|
|
|
for (auto *Method : BR->methods()) {
|
2018-09-03 23:25:27 +08:00
|
|
|
if (!Method->isVirtual() || !Method->getIdentifier())
|
2018-08-23 21:14:50 +08:00
|
|
|
continue;
|
|
|
|
const auto it = Overrides.find(Method->getName());
|
|
|
|
bool IsOverriden = false;
|
|
|
|
if (it != Overrides.end()) {
|
|
|
|
for (auto *MD : it->second) {
|
|
|
|
// If the method in current body is not an overload of this virtual
|
2018-09-03 23:25:27 +08:00
|
|
|
// function, then it overrides this one.
|
2018-08-23 21:14:50 +08:00
|
|
|
if (!S->IsOverload(MD, Method, false)) {
|
|
|
|
IsOverriden = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!IsOverriden)
|
|
|
|
Results.emplace_back(Method, 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return Results;
|
|
|
|
}
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
/// A code completion result, in clang-native form.
|
|
|
|
/// It may be promoted to a CompletionItem if it's among the top-ranked results.
|
|
|
|
struct CompletionCandidate {
|
|
|
|
llvm::StringRef Name; // Used for filtering and sorting.
|
|
|
|
// We may have a result from Sema, from the index, or both.
|
|
|
|
const CodeCompletionResult *SemaResult = nullptr;
|
|
|
|
const Symbol *IndexResult = nullptr;
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
llvm::SmallVector<StringRef, 1> RankedIncludeHeaders;
|
2017-12-04 21:49:59 +08:00
|
|
|
|
2018-08-23 21:14:50 +08:00
|
|
|
// States whether this item is an override suggestion.
|
|
|
|
bool IsOverride = false;
|
|
|
|
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
// Returns a token identifying the overload set this is part of.
|
|
|
|
// 0 indicates it's not part of any overload set.
|
|
|
|
size_t overloadSet() const {
|
|
|
|
SmallString<256> Scratch;
|
|
|
|
if (IndexResult) {
|
|
|
|
switch (IndexResult->SymInfo.Kind) {
|
|
|
|
case index::SymbolKind::ClassMethod:
|
|
|
|
case index::SymbolKind::InstanceMethod:
|
|
|
|
case index::SymbolKind::StaticMethod:
|
|
|
|
assert(false && "Don't expect members from index in code completion");
|
|
|
|
// fall through
|
|
|
|
case index::SymbolKind::Function:
|
|
|
|
// We can't group overloads together that need different #includes.
|
|
|
|
// This could break #include insertion.
|
|
|
|
return hash_combine(
|
|
|
|
(IndexResult->Scope + IndexResult->Name).toStringRef(Scratch),
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
headerToInsertIfAllowed().getValueOr(""));
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
default:
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
assert(SemaResult);
|
|
|
|
// We need to make sure we're consistent with the IndexResult case!
|
|
|
|
const NamedDecl *D = SemaResult->Declaration;
|
|
|
|
if (!D || !D->isFunctionOrFunctionTemplate())
|
|
|
|
return 0;
|
|
|
|
{
|
|
|
|
llvm::raw_svector_ostream OS(Scratch);
|
|
|
|
D->printQualifiedName(OS);
|
|
|
|
}
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
return hash_combine(Scratch, headerToInsertIfAllowed().getValueOr(""));
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
}
|
|
|
|
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
// The best header to include if include insertion is allowed.
|
|
|
|
llvm::Optional<llvm::StringRef> headerToInsertIfAllowed() const {
|
|
|
|
if (RankedIncludeHeaders.empty())
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
return llvm::None;
|
|
|
|
if (SemaResult && SemaResult->Declaration) {
|
|
|
|
// Avoid inserting new #include if the declaration is found in the current
|
|
|
|
// file e.g. the symbol is forward declared.
|
|
|
|
auto &SM = SemaResult->Declaration->getASTContext().getSourceManager();
|
|
|
|
for (const Decl *RD : SemaResult->Declaration->redecls())
|
2018-08-10 06:42:26 +08:00
|
|
|
if (SM.isInMainFile(SM.getExpansionLoc(RD->getBeginLoc())))
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
return llvm::None;
|
|
|
|
}
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
return RankedIncludeHeaders[0];
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
using Bundle = llvm::SmallVector<CompletionCandidate, 4>;
|
|
|
|
};
|
|
|
|
using ScoredBundle =
|
2018-06-29 22:47:57 +08:00
|
|
|
std::pair<CompletionCandidate::Bundle, CodeCompletion::Scores>;
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
struct ScoredBundleGreater {
|
|
|
|
bool operator()(const ScoredBundle &L, const ScoredBundle &R) {
|
2018-06-29 22:47:57 +08:00
|
|
|
if (L.second.Total != R.second.Total)
|
|
|
|
return L.second.Total > R.second.Total;
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
return L.first.front().Name <
|
|
|
|
R.first.front().Name; // Earlier name is better.
|
|
|
|
}
|
2017-12-04 21:49:59 +08:00
|
|
|
};
|
|
|
|
|
2018-06-29 22:47:57 +08:00
|
|
|
// Assembles a code completion out of a bundle of >=1 completion candidates.
|
|
|
|
// Many of the expensive strings are only computed at this point, once we know
|
|
|
|
// the candidate bundle is going to be returned.
|
|
|
|
//
|
|
|
|
// Many fields are the same for all candidates in a bundle (e.g. name), and are
|
|
|
|
// computed from the first candidate, in the constructor.
|
|
|
|
// Others vary per candidate, so add() must be called for remaining candidates.
|
|
|
|
struct CodeCompletionBuilder {
|
|
|
|
CodeCompletionBuilder(ASTContext &ASTCtx, const CompletionCandidate &C,
|
|
|
|
CodeCompletionString *SemaCCS,
|
|
|
|
const IncludeInserter &Includes, StringRef FileName,
|
|
|
|
const CodeCompleteOptions &Opts)
|
2018-08-23 20:19:39 +08:00
|
|
|
: ASTCtx(ASTCtx), ExtractDocumentation(Opts.IncludeComments),
|
|
|
|
EnableFunctionArgSnippets(Opts.EnableFunctionArgSnippets) {
|
2018-06-29 22:47:57 +08:00
|
|
|
add(C, SemaCCS);
|
|
|
|
if (C.SemaResult) {
|
2018-07-06 19:50:49 +08:00
|
|
|
Completion.Origin |= SymbolOrigin::AST;
|
2018-06-29 22:47:57 +08:00
|
|
|
Completion.Name = llvm::StringRef(SemaCCS->getTypedText());
|
2018-07-18 23:31:14 +08:00
|
|
|
if (Completion.Scope.empty()) {
|
|
|
|
if ((C.SemaResult->Kind == CodeCompletionResult::RK_Declaration) ||
|
|
|
|
(C.SemaResult->Kind == CodeCompletionResult::RK_Pattern))
|
2018-06-29 22:47:57 +08:00
|
|
|
if (const auto *D = C.SemaResult->getDeclaration())
|
|
|
|
if (const auto *ND = llvm::dyn_cast<NamedDecl>(D))
|
|
|
|
Completion.Scope =
|
|
|
|
splitQualifiedName(printQualifiedName(*ND)).first;
|
2018-07-18 23:31:14 +08:00
|
|
|
}
|
2018-06-29 22:47:57 +08:00
|
|
|
Completion.Kind =
|
|
|
|
toCompletionItemKind(C.SemaResult->Kind, C.SemaResult->Declaration);
|
2018-08-08 16:59:29 +08:00
|
|
|
for (const auto &FixIt : C.SemaResult->FixIts) {
|
|
|
|
Completion.FixIts.push_back(
|
|
|
|
toTextEdit(FixIt, ASTCtx.getSourceManager(), ASTCtx.getLangOpts()));
|
|
|
|
}
|
2018-08-13 16:23:01 +08:00
|
|
|
std::sort(Completion.FixIts.begin(), Completion.FixIts.end(),
|
|
|
|
[](const TextEdit &X, const TextEdit &Y) {
|
|
|
|
return std::tie(X.range.start.line, X.range.start.character) <
|
|
|
|
std::tie(Y.range.start.line, Y.range.start.character);
|
|
|
|
});
|
2018-06-29 22:47:57 +08:00
|
|
|
}
|
|
|
|
if (C.IndexResult) {
|
2018-07-06 19:50:49 +08:00
|
|
|
Completion.Origin |= C.IndexResult->Origin;
|
2018-06-29 22:47:57 +08:00
|
|
|
if (Completion.Scope.empty())
|
|
|
|
Completion.Scope = C.IndexResult->Scope;
|
|
|
|
if (Completion.Kind == CompletionItemKind::Missing)
|
|
|
|
Completion.Kind = toCompletionItemKind(C.IndexResult->SymInfo.Kind);
|
|
|
|
if (Completion.Name.empty())
|
|
|
|
Completion.Name = C.IndexResult->Name;
|
|
|
|
}
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
|
|
|
|
// Turn absolute path into a literal string that can be #included.
|
|
|
|
auto Inserted =
|
|
|
|
[&](StringRef Header) -> Expected<std::pair<std::string, bool>> {
|
|
|
|
auto ResolvedDeclaring =
|
|
|
|
toHeaderFile(C.IndexResult->CanonicalDeclaration.FileURI, FileName);
|
|
|
|
if (!ResolvedDeclaring)
|
|
|
|
return ResolvedDeclaring.takeError();
|
|
|
|
auto ResolvedInserted = toHeaderFile(Header, FileName);
|
|
|
|
if (!ResolvedInserted)
|
|
|
|
return ResolvedInserted.takeError();
|
|
|
|
return std::make_pair(
|
|
|
|
Includes.calculateIncludePath(*ResolvedDeclaring, *ResolvedInserted),
|
|
|
|
Includes.shouldInsertInclude(*ResolvedDeclaring, *ResolvedInserted));
|
|
|
|
};
|
|
|
|
bool ShouldInsert = C.headerToInsertIfAllowed().hasValue();
|
|
|
|
// Calculate include paths and edits for all possible headers.
|
|
|
|
for (const auto &Inc : C.RankedIncludeHeaders) {
|
|
|
|
if (auto ToInclude = Inserted(Inc)) {
|
|
|
|
CodeCompletion::IncludeCandidate Include;
|
|
|
|
Include.Header = ToInclude->first;
|
|
|
|
if (ToInclude->second && ShouldInsert)
|
|
|
|
Include.Insertion = Includes.insert(ToInclude->first);
|
|
|
|
Completion.Includes.push_back(std::move(Include));
|
2018-06-29 22:47:57 +08:00
|
|
|
} else
|
[clangd] Upgrade logging facilities with levels and formatv.
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
2018-07-11 18:35:11 +08:00
|
|
|
log("Failed to generate include insertion edits for adding header "
|
2018-06-29 22:47:57 +08:00
|
|
|
"(FileURI='{0}', IncludeHeader='{1}') into {2}",
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
C.IndexResult->CanonicalDeclaration.FileURI, Inc, FileName);
|
2018-06-29 22:47:57 +08:00
|
|
|
}
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
// Prefer includes that do not need edits (i.e. already exist).
|
|
|
|
std::stable_partition(Completion.Includes.begin(),
|
|
|
|
Completion.Includes.end(),
|
|
|
|
[](const CodeCompletion::IncludeCandidate &I) {
|
|
|
|
return !I.Insertion.hasValue();
|
|
|
|
});
|
2018-06-29 22:47:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void add(const CompletionCandidate &C, CodeCompletionString *SemaCCS) {
|
|
|
|
assert(bool(C.SemaResult) == bool(SemaCCS));
|
|
|
|
Bundled.emplace_back();
|
|
|
|
BundledEntry &S = Bundled.back();
|
|
|
|
if (C.SemaResult) {
|
|
|
|
getSignature(*SemaCCS, &S.Signature, &S.SnippetSuffix,
|
|
|
|
&Completion.RequiredQualifier);
|
|
|
|
S.ReturnType = getReturnType(*SemaCCS);
|
|
|
|
} else if (C.IndexResult) {
|
|
|
|
S.Signature = C.IndexResult->Signature;
|
|
|
|
S.SnippetSuffix = C.IndexResult->CompletionSnippetSuffix;
|
2018-08-31 21:55:01 +08:00
|
|
|
S.ReturnType = C.IndexResult->ReturnType;
|
2018-06-29 22:47:57 +08:00
|
|
|
}
|
|
|
|
if (ExtractDocumentation && Completion.Documentation.empty()) {
|
2018-08-31 21:55:01 +08:00
|
|
|
if (C.IndexResult)
|
|
|
|
Completion.Documentation = C.IndexResult->Documentation;
|
2018-06-29 22:47:57 +08:00
|
|
|
else if (C.SemaResult)
|
|
|
|
Completion.Documentation = getDocComment(ASTCtx, *C.SemaResult,
|
|
|
|
/*CommentsFromHeader=*/false);
|
|
|
|
}
|
2018-08-23 21:14:50 +08:00
|
|
|
if (C.IsOverride)
|
|
|
|
S.OverrideSuffix = true;
|
2018-06-29 22:47:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
CodeCompletion build() {
|
|
|
|
Completion.ReturnType = summarizeReturnType();
|
|
|
|
Completion.Signature = summarizeSignature();
|
|
|
|
Completion.SnippetSuffix = summarizeSnippet();
|
|
|
|
Completion.BundleSize = Bundled.size();
|
2018-08-23 21:14:50 +08:00
|
|
|
if (summarizeOverride()) {
|
|
|
|
Completion.Name = Completion.ReturnType + ' ' +
|
|
|
|
std::move(Completion.Name) +
|
|
|
|
std::move(Completion.Signature) + " override";
|
|
|
|
Completion.Signature.clear();
|
|
|
|
}
|
2018-06-29 22:47:57 +08:00
|
|
|
return std::move(Completion);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
struct BundledEntry {
|
|
|
|
std::string SnippetSuffix;
|
|
|
|
std::string Signature;
|
|
|
|
std::string ReturnType;
|
2018-08-23 21:14:50 +08:00
|
|
|
bool OverrideSuffix;
|
2018-06-29 22:47:57 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
// If all BundledEntrys have the same value for a property, return it.
|
|
|
|
template <std::string BundledEntry::*Member>
|
|
|
|
const std::string *onlyValue() const {
|
|
|
|
auto B = Bundled.begin(), E = Bundled.end();
|
|
|
|
for (auto I = B + 1; I != E; ++I)
|
|
|
|
if (I->*Member != B->*Member)
|
|
|
|
return nullptr;
|
|
|
|
return &(B->*Member);
|
|
|
|
}
|
|
|
|
|
2018-08-23 21:14:50 +08:00
|
|
|
template <bool BundledEntry::*Member> const bool *onlyValue() const {
|
|
|
|
auto B = Bundled.begin(), E = Bundled.end();
|
|
|
|
for (auto I = B + 1; I != E; ++I)
|
|
|
|
if (I->*Member != B->*Member)
|
|
|
|
return nullptr;
|
|
|
|
return &(B->*Member);
|
|
|
|
}
|
|
|
|
|
2018-06-29 22:47:57 +08:00
|
|
|
std::string summarizeReturnType() const {
|
|
|
|
if (auto *RT = onlyValue<&BundledEntry::ReturnType>())
|
|
|
|
return *RT;
|
|
|
|
return "";
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string summarizeSnippet() const {
|
2018-08-23 20:19:39 +08:00
|
|
|
auto *Snippet = onlyValue<&BundledEntry::SnippetSuffix>();
|
|
|
|
if (!Snippet)
|
|
|
|
// All bundles are function calls.
|
|
|
|
return "($0)";
|
|
|
|
if (!Snippet->empty() && !EnableFunctionArgSnippets &&
|
|
|
|
((Completion.Kind == CompletionItemKind::Function) ||
|
|
|
|
(Completion.Kind == CompletionItemKind::Method)) &&
|
|
|
|
(Snippet->front() == '(') && (Snippet->back() == ')'))
|
|
|
|
// Check whether function has any parameters or not.
|
|
|
|
return Snippet->size() > 2 ? "($0)" : "()";
|
|
|
|
return *Snippet;
|
2018-06-29 22:47:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
std::string summarizeSignature() const {
|
|
|
|
if (auto *Signature = onlyValue<&BundledEntry::Signature>())
|
|
|
|
return *Signature;
|
|
|
|
// All bundles are function calls.
|
|
|
|
return "(…)";
|
|
|
|
}
|
|
|
|
|
2018-08-23 21:14:50 +08:00
|
|
|
bool summarizeOverride() const {
|
|
|
|
if (auto *OverrideSuffix = onlyValue<&BundledEntry::OverrideSuffix>())
|
|
|
|
return *OverrideSuffix;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-06-29 22:47:57 +08:00
|
|
|
ASTContext &ASTCtx;
|
|
|
|
CodeCompletion Completion;
|
|
|
|
SmallVector<BundledEntry, 1> Bundled;
|
|
|
|
bool ExtractDocumentation;
|
2018-08-23 20:19:39 +08:00
|
|
|
bool EnableFunctionArgSnippets;
|
2018-06-29 22:47:57 +08:00
|
|
|
};
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// Determine the symbol ID for a Sema code completion result, if possible.
|
|
|
|
llvm::Optional<SymbolID> getSymbolID(const CodeCompletionResult &R) {
|
|
|
|
switch (R.Kind) {
|
|
|
|
case CodeCompletionResult::RK_Declaration:
|
|
|
|
case CodeCompletionResult::RK_Pattern: {
|
2018-08-07 16:57:52 +08:00
|
|
|
return clang::clangd::getSymbolID(R.Declaration);
|
2018-01-19 22:34:02 +08:00
|
|
|
}
|
|
|
|
case CodeCompletionResult::RK_Macro:
|
|
|
|
// FIXME: Macros do have USRs, but the CCR doesn't contain enough info.
|
|
|
|
case CodeCompletionResult::RK_Keyword:
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
llvm_unreachable("unknown CodeCompletionResult kind");
|
|
|
|
}
|
|
|
|
|
2018-01-23 19:37:26 +08:00
|
|
|
// Scopes of the paritial identifier we're trying to complete.
|
|
|
|
// It is used when we query the index for more completion results.
|
2017-12-20 00:50:37 +08:00
|
|
|
struct SpecifiedScope {
|
2018-01-23 19:37:26 +08:00
|
|
|
// The scopes we should look in, determined by Sema.
|
|
|
|
//
|
|
|
|
// If the qualifier was fully resolved, we look for completions in these
|
|
|
|
// scopes; if there is an unresolved part of the qualifier, it should be
|
|
|
|
// resolved within these scopes.
|
|
|
|
//
|
|
|
|
// Examples of qualified completion:
|
|
|
|
//
|
|
|
|
// "::vec" => {""}
|
|
|
|
// "using namespace std; ::vec^" => {"", "std::"}
|
|
|
|
// "namespace ns {using namespace std;} ns::^" => {"ns::", "std::"}
|
|
|
|
// "std::vec^" => {""} // "std" unresolved
|
|
|
|
//
|
|
|
|
// Examples of unqualified completion:
|
|
|
|
//
|
|
|
|
// "vec^" => {""}
|
|
|
|
// "using namespace std; vec^" => {"", "std::"}
|
|
|
|
// "using namespace std; namespace ns { vec^ }" => {"ns::", "std::", ""}
|
|
|
|
//
|
|
|
|
// "" for global namespace, "ns::" for normal namespace.
|
|
|
|
std::vector<std::string> AccessibleScopes;
|
|
|
|
// The full scope qualifier as typed by the user (without the leading "::").
|
|
|
|
// Set if the qualifier is not fully resolved by Sema.
|
|
|
|
llvm::Optional<std::string> UnresolvedQualifier;
|
|
|
|
|
|
|
|
// Construct scopes being queried in indexes.
|
|
|
|
// This method format the scopes to match the index request representation.
|
|
|
|
std::vector<std::string> scopesForIndexQuery() {
|
|
|
|
std::vector<std::string> Results;
|
|
|
|
for (llvm::StringRef AS : AccessibleScopes) {
|
|
|
|
Results.push_back(AS);
|
|
|
|
if (UnresolvedQualifier)
|
|
|
|
Results.back() += *UnresolvedQualifier;
|
|
|
|
}
|
|
|
|
return Results;
|
2018-01-19 22:34:02 +08:00
|
|
|
}
|
2017-12-20 00:50:37 +08:00
|
|
|
};
|
|
|
|
|
2018-01-23 19:37:26 +08:00
|
|
|
// Get all scopes that will be queried in indexes.
|
|
|
|
std::vector<std::string> getQueryScopes(CodeCompletionContext &CCContext,
|
2018-05-29 19:50:51 +08:00
|
|
|
const SourceManager &SM) {
|
|
|
|
auto GetAllAccessibleScopes = [](CodeCompletionContext &CCContext) {
|
2018-01-23 19:37:26 +08:00
|
|
|
SpecifiedScope Info;
|
2018-05-29 19:50:51 +08:00
|
|
|
for (auto *Context : CCContext.getVisitedContexts()) {
|
2018-01-23 19:37:26 +08:00
|
|
|
if (isa<TranslationUnitDecl>(Context))
|
|
|
|
Info.AccessibleScopes.push_back(""); // global namespace
|
2018-05-29 19:50:51 +08:00
|
|
|
else if (const auto *NS = dyn_cast<NamespaceDecl>(Context))
|
2018-01-23 19:37:26 +08:00
|
|
|
Info.AccessibleScopes.push_back(NS->getQualifiedNameAsString() + "::");
|
|
|
|
}
|
|
|
|
return Info;
|
|
|
|
};
|
|
|
|
|
|
|
|
auto SS = CCContext.getCXXScopeSpecifier();
|
|
|
|
|
|
|
|
// Unqualified completion (e.g. "vec^").
|
|
|
|
if (!SS) {
|
|
|
|
// FIXME: Once we can insert namespace qualifiers and use the in-scope
|
|
|
|
// namespaces for scoring, search in all namespaces.
|
|
|
|
// FIXME: Capture scopes and use for scoring, for example,
|
|
|
|
// "using namespace std; namespace foo {v^}" =>
|
|
|
|
// foo::value > std::vector > boost::variant
|
|
|
|
return GetAllAccessibleScopes(CCContext).scopesForIndexQuery();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Qualified completion ("std::vec^"), we have two cases depending on whether
|
|
|
|
// the qualifier can be resolved by Sema.
|
|
|
|
if ((*SS)->isValid()) { // Resolved qualifier.
|
|
|
|
return GetAllAccessibleScopes(CCContext).scopesForIndexQuery();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Unresolved qualifier.
|
|
|
|
// FIXME: When Sema can resolve part of a scope chain (e.g.
|
|
|
|
// "known::unknown::id"), we should expand the known part ("known::") rather
|
|
|
|
// than treating the whole thing as unknown.
|
|
|
|
SpecifiedScope Info;
|
|
|
|
Info.AccessibleScopes.push_back(""); // global namespace
|
|
|
|
|
|
|
|
Info.UnresolvedQualifier =
|
2018-05-29 19:50:51 +08:00
|
|
|
Lexer::getSourceText(CharSourceRange::getCharRange((*SS)->getRange()), SM,
|
|
|
|
clang::LangOptions())
|
|
|
|
.ltrim("::");
|
2018-01-23 19:37:26 +08:00
|
|
|
// Sema excludes the trailing "::".
|
|
|
|
if (!Info.UnresolvedQualifier->empty())
|
|
|
|
*Info.UnresolvedQualifier += "::";
|
|
|
|
|
|
|
|
return Info.scopesForIndexQuery();
|
|
|
|
}
|
|
|
|
|
2018-05-24 19:20:19 +08:00
|
|
|
// Should we perform index-based completion in a context of the specified kind?
|
|
|
|
// FIXME: consider allowing completion, but restricting the result types.
|
|
|
|
bool contextAllowsIndex(enum CodeCompletionContext::Kind K) {
|
|
|
|
switch (K) {
|
|
|
|
case CodeCompletionContext::CCC_TopLevel:
|
|
|
|
case CodeCompletionContext::CCC_ObjCInterface:
|
|
|
|
case CodeCompletionContext::CCC_ObjCImplementation:
|
|
|
|
case CodeCompletionContext::CCC_ObjCIvarList:
|
|
|
|
case CodeCompletionContext::CCC_ClassStructUnion:
|
|
|
|
case CodeCompletionContext::CCC_Statement:
|
|
|
|
case CodeCompletionContext::CCC_Expression:
|
|
|
|
case CodeCompletionContext::CCC_ObjCMessageReceiver:
|
|
|
|
case CodeCompletionContext::CCC_EnumTag:
|
|
|
|
case CodeCompletionContext::CCC_UnionTag:
|
|
|
|
case CodeCompletionContext::CCC_ClassOrStructTag:
|
|
|
|
case CodeCompletionContext::CCC_ObjCProtocolName:
|
|
|
|
case CodeCompletionContext::CCC_Namespace:
|
|
|
|
case CodeCompletionContext::CCC_Type:
|
|
|
|
case CodeCompletionContext::CCC_Name: // FIXME: why does ns::^ give this?
|
|
|
|
case CodeCompletionContext::CCC_PotentiallyQualifiedName:
|
|
|
|
case CodeCompletionContext::CCC_ParenthesizedExpression:
|
|
|
|
case CodeCompletionContext::CCC_ObjCInterfaceName:
|
|
|
|
case CodeCompletionContext::CCC_ObjCCategoryName:
|
|
|
|
return true;
|
|
|
|
case CodeCompletionContext::CCC_Other: // Be conservative.
|
|
|
|
case CodeCompletionContext::CCC_OtherWithMacros:
|
|
|
|
case CodeCompletionContext::CCC_DotMemberAccess:
|
|
|
|
case CodeCompletionContext::CCC_ArrowMemberAccess:
|
|
|
|
case CodeCompletionContext::CCC_ObjCPropertyAccess:
|
|
|
|
case CodeCompletionContext::CCC_MacroName:
|
|
|
|
case CodeCompletionContext::CCC_MacroNameUse:
|
|
|
|
case CodeCompletionContext::CCC_PreprocessorExpression:
|
|
|
|
case CodeCompletionContext::CCC_PreprocessorDirective:
|
|
|
|
case CodeCompletionContext::CCC_NaturalLanguage:
|
|
|
|
case CodeCompletionContext::CCC_SelectorName:
|
|
|
|
case CodeCompletionContext::CCC_TypeQualifiers:
|
|
|
|
case CodeCompletionContext::CCC_ObjCInstanceMessage:
|
|
|
|
case CodeCompletionContext::CCC_ObjCClassMessage:
|
|
|
|
case CodeCompletionContext::CCC_Recovery:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
llvm_unreachable("unknown code completion context");
|
|
|
|
}
|
|
|
|
|
2018-06-07 20:49:17 +08:00
|
|
|
// Some member calls are blacklisted because they're so rarely useful.
|
|
|
|
static bool isBlacklistedMember(const NamedDecl &D) {
|
|
|
|
// Destructor completion is rarely useful, and works inconsistently.
|
|
|
|
// (s.^ completes ~string, but s.~st^ is an error).
|
|
|
|
if (D.getKind() == Decl::CXXDestructor)
|
|
|
|
return true;
|
|
|
|
// Injected name may be useful for A::foo(), but who writes A::A::foo()?
|
|
|
|
if (auto *R = dyn_cast_or_null<RecordDecl>(&D))
|
|
|
|
if (R->isInjectedClassName())
|
|
|
|
return true;
|
|
|
|
// Explicit calls to operators are also rare.
|
|
|
|
auto NameKind = D.getDeclName().getNameKind();
|
|
|
|
if (NameKind == DeclarationName::CXXOperatorName ||
|
|
|
|
NameKind == DeclarationName::CXXLiteralOperatorName ||
|
|
|
|
NameKind == DeclarationName::CXXConversionFunctionName)
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// The CompletionRecorder captures Sema code-complete output, including context.
|
|
|
|
// It filters out ignored results (but doesn't apply fuzzy-filtering yet).
|
|
|
|
// It doesn't do scoring or conversion to CompletionItem yet, as we want to
|
|
|
|
// merge with index results first.
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
// Generally the fields and methods of this object should only be used from
|
|
|
|
// within the callback.
|
2018-01-19 22:34:02 +08:00
|
|
|
struct CompletionRecorder : public CodeCompleteConsumer {
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
CompletionRecorder(const CodeCompleteOptions &Opts,
|
2018-07-04 04:59:33 +08:00
|
|
|
llvm::unique_function<void()> ResultsCallback)
|
2018-01-19 22:34:02 +08:00
|
|
|
: CodeCompleteConsumer(Opts.getClangCompleteOpts(),
|
2017-12-04 21:49:59 +08:00
|
|
|
/*OutputIsBinary=*/false),
|
2018-01-19 22:34:02 +08:00
|
|
|
CCContext(CodeCompletionContext::CCC_Other), Opts(Opts),
|
|
|
|
CCAllocator(std::make_shared<GlobalCodeCompletionAllocator>()),
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
CCTUInfo(CCAllocator), ResultsCallback(std::move(ResultsCallback)) {
|
|
|
|
assert(this->ResultsCallback);
|
|
|
|
}
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
std::vector<CodeCompletionResult> Results;
|
|
|
|
CodeCompletionContext CCContext;
|
|
|
|
Sema *CCSema = nullptr; // Sema that created the results.
|
|
|
|
// FIXME: Sema is scary. Can we store ASTContext and Preprocessor, instead?
|
|
|
|
|
|
|
|
void ProcessCodeCompleteResults(class Sema &S, CodeCompletionContext Context,
|
|
|
|
CodeCompletionResult *InResults,
|
2017-12-04 21:49:59 +08:00
|
|
|
unsigned NumResults) override final {
|
2018-07-11 21:15:31 +08:00
|
|
|
// Results from recovery mode are generally useless, and the callback after
|
|
|
|
// recovery (if any) is usually more interesting. To make sure we handle the
|
|
|
|
// future callback from sema, we just ignore all callbacks in recovery mode,
|
|
|
|
// as taking only results from recovery mode results in poor completion
|
|
|
|
// results.
|
|
|
|
// FIXME: in case there is no future sema completion callback after the
|
|
|
|
// recovery mode, we might still want to provide some results (e.g. trivial
|
|
|
|
// identifier-based completion).
|
|
|
|
if (Context.getKind() == CodeCompletionContext::CCC_Recovery) {
|
|
|
|
log("Code complete: Ignoring sema code complete callback with Recovery "
|
|
|
|
"context.");
|
|
|
|
return;
|
|
|
|
}
|
2018-05-24 19:20:19 +08:00
|
|
|
// If a callback is called without any sema result and the context does not
|
|
|
|
// support index-based completion, we simply skip it to give way to
|
|
|
|
// potential future callbacks with results.
|
|
|
|
if (NumResults == 0 && !contextAllowsIndex(Context.getKind()))
|
|
|
|
return;
|
2018-03-16 23:23:44 +08:00
|
|
|
if (CCSema) {
|
[clangd] Upgrade logging facilities with levels and formatv.
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
2018-07-11 18:35:11 +08:00
|
|
|
log("Multiple code complete callbacks (parser backtracked?). "
|
2018-03-16 23:23:44 +08:00
|
|
|
"Dropping results from context {0}, keeping results from {1}.",
|
2018-05-24 19:20:19 +08:00
|
|
|
getCompletionKindString(Context.getKind()),
|
[clangd] Upgrade logging facilities with levels and formatv.
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
2018-07-11 18:35:11 +08:00
|
|
|
getCompletionKindString(this->CCContext.getKind()));
|
2018-03-16 23:23:44 +08:00
|
|
|
return;
|
|
|
|
}
|
2018-01-19 22:34:02 +08:00
|
|
|
// Record the completion context.
|
|
|
|
CCSema = &S;
|
|
|
|
CCContext = Context;
|
2017-12-20 00:50:37 +08:00
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// Retain the results we might want.
|
2017-12-04 21:49:59 +08:00
|
|
|
for (unsigned I = 0; I < NumResults; ++I) {
|
2018-01-19 22:34:02 +08:00
|
|
|
auto &Result = InResults[I];
|
|
|
|
// Drop hidden items which cannot be found by lookup after completion.
|
|
|
|
// Exception: some items can be named by using a qualifier.
|
2018-01-10 21:51:09 +08:00
|
|
|
if (Result.Hidden && (!Result.Qualifier || Result.QualifierIsInformative))
|
|
|
|
continue;
|
2018-01-19 22:34:02 +08:00
|
|
|
if (!Opts.IncludeIneligibleResults &&
|
2017-12-04 21:49:59 +08:00
|
|
|
(Result.Availability == CXAvailability_NotAvailable ||
|
|
|
|
Result.Availability == CXAvailability_NotAccessible))
|
|
|
|
continue;
|
2018-06-07 20:49:17 +08:00
|
|
|
if (Result.Declaration &&
|
|
|
|
!Context.getBaseType().isNull() // is this a member-access context?
|
|
|
|
&& isBlacklistedMember(*Result.Declaration))
|
2018-01-23 05:05:00 +08:00
|
|
|
continue;
|
2018-03-07 00:45:21 +08:00
|
|
|
// We choose to never append '::' to completion results in clangd.
|
|
|
|
Result.StartsNestedNameSpecifier = false;
|
2018-01-19 22:34:02 +08:00
|
|
|
Results.push_back(Result);
|
2017-12-04 21:49:59 +08:00
|
|
|
}
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
ResultsCallback();
|
2017-12-04 21:49:59 +08:00
|
|
|
}
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
CodeCompletionAllocator &getAllocator() override { return *CCAllocator; }
|
2017-12-04 21:49:59 +08:00
|
|
|
CodeCompletionTUInfo &getCodeCompletionTUInfo() override { return CCTUInfo; }
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// Returns the filtering/sorting name for Result, which must be from Results.
|
|
|
|
// Returned string is owned by this recorder (or the AST).
|
|
|
|
llvm::StringRef getName(const CodeCompletionResult &Result) {
|
2017-12-04 21:49:59 +08:00
|
|
|
switch (Result.Kind) {
|
|
|
|
case CodeCompletionResult::RK_Declaration:
|
|
|
|
if (auto *ID = Result.Declaration->getIdentifier())
|
2018-01-19 22:34:02 +08:00
|
|
|
return ID->getName();
|
2017-12-04 21:49:59 +08:00
|
|
|
break;
|
|
|
|
case CodeCompletionResult::RK_Keyword:
|
2018-01-19 22:34:02 +08:00
|
|
|
return Result.Keyword;
|
2017-12-04 21:49:59 +08:00
|
|
|
case CodeCompletionResult::RK_Macro:
|
2018-01-19 22:34:02 +08:00
|
|
|
return Result.Macro->getName();
|
2017-12-04 21:49:59 +08:00
|
|
|
case CodeCompletionResult::RK_Pattern:
|
2018-01-19 22:34:02 +08:00
|
|
|
return Result.Pattern->getTypedText();
|
2017-12-04 21:49:59 +08:00
|
|
|
}
|
2018-05-16 20:32:44 +08:00
|
|
|
auto *CCS = codeCompletionString(Result);
|
2018-01-19 22:34:02 +08:00
|
|
|
return CCS->getTypedText();
|
2017-12-04 21:49:59 +08:00
|
|
|
}
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// Build a CodeCompletion string for R, which must be from Results.
|
|
|
|
// The CCS will be owned by this recorder.
|
2018-05-16 20:32:44 +08:00
|
|
|
CodeCompletionString *codeCompletionString(const CodeCompletionResult &R) {
|
2018-01-19 22:34:02 +08:00
|
|
|
// CodeCompletionResult doesn't seem to be const-correct. We own it, anyway.
|
|
|
|
return const_cast<CodeCompletionResult &>(R).CreateCodeCompletionString(
|
2018-05-16 20:32:44 +08:00
|
|
|
*CCSema, CCContext, *CCAllocator, CCTUInfo,
|
|
|
|
/*IncludeBriefComments=*/false);
|
2018-01-19 22:34:02 +08:00
|
|
|
}
|
2017-12-04 21:49:59 +08:00
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
private:
|
|
|
|
CodeCompleteOptions Opts;
|
|
|
|
std::shared_ptr<GlobalCodeCompletionAllocator> CCAllocator;
|
|
|
|
CodeCompletionTUInfo CCTUInfo;
|
2018-07-04 04:59:33 +08:00
|
|
|
llvm::unique_function<void()> ResultsCallback;
|
2018-01-19 22:34:02 +08:00
|
|
|
};
|
2017-12-21 01:24:31 +08:00
|
|
|
|
2018-08-17 17:32:30 +08:00
|
|
|
struct ScoredSignature {
|
|
|
|
// When set, requires documentation to be requested from the index with this
|
|
|
|
// ID.
|
|
|
|
llvm::Optional<SymbolID> IDForDoc;
|
|
|
|
SignatureInformation Signature;
|
|
|
|
SignatureQualitySignals Quality;
|
|
|
|
};
|
2018-08-13 16:40:05 +08:00
|
|
|
|
2017-12-04 21:49:59 +08:00
|
|
|
class SignatureHelpCollector final : public CodeCompleteConsumer {
|
|
|
|
public:
|
|
|
|
SignatureHelpCollector(const clang::CodeCompleteOptions &CodeCompleteOpts,
|
2018-08-17 17:32:30 +08:00
|
|
|
SymbolIndex *Index, SignatureHelp &SigHelp)
|
|
|
|
: CodeCompleteConsumer(CodeCompleteOpts,
|
|
|
|
/*OutputIsBinary=*/false),
|
2017-12-04 21:49:59 +08:00
|
|
|
SigHelp(SigHelp),
|
|
|
|
Allocator(std::make_shared<clang::GlobalCodeCompletionAllocator>()),
|
2018-08-17 17:32:30 +08:00
|
|
|
CCTUInfo(Allocator), Index(Index) {}
|
2017-12-04 21:49:59 +08:00
|
|
|
|
|
|
|
void ProcessOverloadCandidates(Sema &S, unsigned CurrentArg,
|
|
|
|
OverloadCandidate *Candidates,
|
2018-08-30 21:14:31 +08:00
|
|
|
unsigned NumCandidates,
|
|
|
|
SourceLocation OpenParLoc) override {
|
|
|
|
assert(!OpenParLoc.isInvalid());
|
|
|
|
SourceManager &SrcMgr = S.getSourceManager();
|
|
|
|
OpenParLoc = SrcMgr.getFileLoc(OpenParLoc);
|
|
|
|
if (SrcMgr.isInMainFile(OpenParLoc))
|
|
|
|
SigHelp.argListStart = sourceLocToPosition(SrcMgr, OpenParLoc);
|
|
|
|
else
|
|
|
|
elog("Location oustide main file in signature help: {0}",
|
|
|
|
OpenParLoc.printToString(SrcMgr));
|
|
|
|
|
2018-08-13 16:40:05 +08:00
|
|
|
std::vector<ScoredSignature> ScoredSignatures;
|
2017-12-04 21:49:59 +08:00
|
|
|
SigHelp.signatures.reserve(NumCandidates);
|
2018-08-13 16:40:05 +08:00
|
|
|
ScoredSignatures.reserve(NumCandidates);
|
2017-12-04 21:49:59 +08:00
|
|
|
// FIXME(rwols): How can we determine the "active overload candidate"?
|
|
|
|
// Right now the overloaded candidates seem to be provided in a "best fit"
|
|
|
|
// order, so I'm not too worried about this.
|
|
|
|
SigHelp.activeSignature = 0;
|
|
|
|
assert(CurrentArg <= (unsigned)std::numeric_limits<int>::max() &&
|
|
|
|
"too many arguments");
|
|
|
|
SigHelp.activeParameter = static_cast<int>(CurrentArg);
|
|
|
|
for (unsigned I = 0; I < NumCandidates; ++I) {
|
2018-08-14 17:36:32 +08:00
|
|
|
OverloadCandidate Candidate = Candidates[I];
|
|
|
|
// We want to avoid showing instantiated signatures, because they may be
|
|
|
|
// long in some cases (e.g. when 'T' is substituted with 'std::string', we
|
|
|
|
// would get 'std::basic_string<char>').
|
|
|
|
if (auto *Func = Candidate.getFunction()) {
|
|
|
|
if (auto *Pattern = Func->getTemplateInstantiationPattern())
|
|
|
|
Candidate = OverloadCandidate(Pattern);
|
|
|
|
}
|
|
|
|
|
2017-12-04 21:49:59 +08:00
|
|
|
const auto *CCS = Candidate.CreateSignatureString(
|
|
|
|
CurrentArg, S, *Allocator, CCTUInfo, true);
|
|
|
|
assert(CCS && "Expected the CodeCompletionString to be non-null");
|
2018-08-13 16:40:05 +08:00
|
|
|
ScoredSignatures.push_back(processOverloadCandidate(
|
2018-05-16 20:32:44 +08:00
|
|
|
Candidate, *CCS,
|
2018-08-17 17:29:38 +08:00
|
|
|
Candidate.getFunction()
|
|
|
|
? getDeclComment(S.getASTContext(), *Candidate.getFunction())
|
|
|
|
: ""));
|
2017-12-04 21:49:59 +08:00
|
|
|
}
|
2018-08-17 17:32:30 +08:00
|
|
|
|
|
|
|
// Sema does not load the docs from the preamble, so we need to fetch extra
|
|
|
|
// docs from the index instead.
|
|
|
|
llvm::DenseMap<SymbolID, std::string> FetchedDocs;
|
|
|
|
if (Index) {
|
|
|
|
LookupRequest IndexRequest;
|
|
|
|
for (const auto &S : ScoredSignatures) {
|
|
|
|
if (!S.IDForDoc)
|
|
|
|
continue;
|
|
|
|
IndexRequest.IDs.insert(*S.IDForDoc);
|
|
|
|
}
|
|
|
|
Index->lookup(IndexRequest, [&](const Symbol &S) {
|
2018-08-31 21:55:01 +08:00
|
|
|
if (!S.Documentation.empty())
|
|
|
|
FetchedDocs[S.ID] = S.Documentation;
|
2018-08-17 17:32:30 +08:00
|
|
|
});
|
|
|
|
log("SigHelp: requested docs for {0} symbols from the index, got {1} "
|
|
|
|
"symbols with non-empty docs in the response",
|
|
|
|
IndexRequest.IDs.size(), FetchedDocs.size());
|
|
|
|
}
|
|
|
|
|
|
|
|
std::sort(
|
|
|
|
ScoredSignatures.begin(), ScoredSignatures.end(),
|
|
|
|
[](const ScoredSignature &L, const ScoredSignature &R) {
|
|
|
|
// Ordering follows:
|
|
|
|
// - Less number of parameters is better.
|
|
|
|
// - Function is better than FunctionType which is better than
|
|
|
|
// Function Template.
|
|
|
|
// - High score is better.
|
|
|
|
// - Shorter signature is better.
|
|
|
|
// - Alphebatically smaller is better.
|
|
|
|
if (L.Quality.NumberOfParameters != R.Quality.NumberOfParameters)
|
|
|
|
return L.Quality.NumberOfParameters < R.Quality.NumberOfParameters;
|
|
|
|
if (L.Quality.NumberOfOptionalParameters !=
|
|
|
|
R.Quality.NumberOfOptionalParameters)
|
|
|
|
return L.Quality.NumberOfOptionalParameters <
|
|
|
|
R.Quality.NumberOfOptionalParameters;
|
|
|
|
if (L.Quality.Kind != R.Quality.Kind) {
|
|
|
|
using OC = CodeCompleteConsumer::OverloadCandidate;
|
|
|
|
switch (L.Quality.Kind) {
|
|
|
|
case OC::CK_Function:
|
|
|
|
return true;
|
|
|
|
case OC::CK_FunctionType:
|
|
|
|
return R.Quality.Kind != OC::CK_Function;
|
|
|
|
case OC::CK_FunctionTemplate:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
llvm_unreachable("Unknown overload candidate type.");
|
|
|
|
}
|
|
|
|
if (L.Signature.label.size() != R.Signature.label.size())
|
|
|
|
return L.Signature.label.size() < R.Signature.label.size();
|
|
|
|
return L.Signature.label < R.Signature.label;
|
|
|
|
});
|
|
|
|
|
|
|
|
for (auto &SS : ScoredSignatures) {
|
|
|
|
auto IndexDocIt =
|
|
|
|
SS.IDForDoc ? FetchedDocs.find(*SS.IDForDoc) : FetchedDocs.end();
|
|
|
|
if (IndexDocIt != FetchedDocs.end())
|
|
|
|
SS.Signature.documentation = IndexDocIt->second;
|
|
|
|
|
|
|
|
SigHelp.signatures.push_back(std::move(SS.Signature));
|
|
|
|
}
|
2017-12-04 21:49:59 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
GlobalCodeCompletionAllocator &getAllocator() override { return *Allocator; }
|
|
|
|
|
|
|
|
CodeCompletionTUInfo &getCodeCompletionTUInfo() override { return CCTUInfo; }
|
|
|
|
|
|
|
|
private:
|
2017-12-21 01:24:31 +08:00
|
|
|
// FIXME(ioeric): consider moving CodeCompletionString logic here to
|
|
|
|
// CompletionString.h.
|
2018-08-13 16:40:05 +08:00
|
|
|
ScoredSignature processOverloadCandidate(const OverloadCandidate &Candidate,
|
|
|
|
const CodeCompletionString &CCS,
|
|
|
|
llvm::StringRef DocComment) const {
|
2018-08-17 17:32:30 +08:00
|
|
|
SignatureInformation Signature;
|
2018-08-13 16:40:05 +08:00
|
|
|
SignatureQualitySignals Signal;
|
2017-12-04 21:49:59 +08:00
|
|
|
const char *ReturnType = nullptr;
|
|
|
|
|
2018-08-17 17:32:30 +08:00
|
|
|
Signature.documentation = formatDocumentation(CCS, DocComment);
|
2018-08-13 16:40:05 +08:00
|
|
|
Signal.Kind = Candidate.getKind();
|
2017-12-04 21:49:59 +08:00
|
|
|
|
|
|
|
for (const auto &Chunk : CCS) {
|
|
|
|
switch (Chunk.Kind) {
|
|
|
|
case CodeCompletionString::CK_ResultType:
|
|
|
|
// A piece of text that describes the type of an entity or,
|
|
|
|
// for functions and methods, the return type.
|
|
|
|
assert(!ReturnType && "Unexpected CK_ResultType");
|
|
|
|
ReturnType = Chunk.Text;
|
|
|
|
break;
|
|
|
|
case CodeCompletionString::CK_Placeholder:
|
|
|
|
// A string that acts as a placeholder for, e.g., a function call
|
|
|
|
// argument.
|
|
|
|
// Intentional fallthrough here.
|
|
|
|
case CodeCompletionString::CK_CurrentParameter: {
|
|
|
|
// A piece of text that describes the parameter that corresponds to
|
|
|
|
// the code-completion location within a function call, message send,
|
|
|
|
// macro invocation, etc.
|
2018-08-17 17:32:30 +08:00
|
|
|
Signature.label += Chunk.Text;
|
2017-12-04 21:49:59 +08:00
|
|
|
ParameterInformation Info;
|
|
|
|
Info.label = Chunk.Text;
|
2018-08-17 17:32:30 +08:00
|
|
|
Signature.parameters.push_back(std::move(Info));
|
2018-08-13 16:40:05 +08:00
|
|
|
Signal.NumberOfParameters++;
|
|
|
|
Signal.ContainsActiveParameter = true;
|
2017-12-04 21:49:59 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case CodeCompletionString::CK_Optional: {
|
|
|
|
// The rest of the parameters are defaulted/optional.
|
|
|
|
assert(Chunk.Optional &&
|
|
|
|
"Expected the optional code completion string to be non-null.");
|
2018-08-17 17:32:30 +08:00
|
|
|
Signature.label += getOptionalParameters(*Chunk.Optional,
|
|
|
|
Signature.parameters, Signal);
|
2017-12-04 21:49:59 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case CodeCompletionString::CK_VerticalSpace:
|
|
|
|
break;
|
|
|
|
default:
|
2018-08-17 17:32:30 +08:00
|
|
|
Signature.label += Chunk.Text;
|
2017-12-04 21:49:59 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (ReturnType) {
|
2018-08-17 17:32:30 +08:00
|
|
|
Signature.label += " -> ";
|
|
|
|
Signature.label += ReturnType;
|
2017-12-04 21:49:59 +08:00
|
|
|
}
|
2018-08-17 17:32:30 +08:00
|
|
|
dlog("Signal for {0}: {1}", Signature, Signal);
|
|
|
|
ScoredSignature Result;
|
|
|
|
Result.Signature = std::move(Signature);
|
|
|
|
Result.Quality = Signal;
|
|
|
|
Result.IDForDoc =
|
|
|
|
Result.Signature.documentation.empty() && Candidate.getFunction()
|
|
|
|
? clangd::getSymbolID(Candidate.getFunction())
|
|
|
|
: llvm::None;
|
|
|
|
return Result;
|
2017-12-04 21:49:59 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
SignatureHelp &SigHelp;
|
|
|
|
std::shared_ptr<clang::GlobalCodeCompletionAllocator> Allocator;
|
|
|
|
CodeCompletionTUInfo CCTUInfo;
|
2018-08-17 17:32:30 +08:00
|
|
|
const SymbolIndex *Index;
|
2017-12-04 21:49:59 +08:00
|
|
|
}; // SignatureHelpCollector
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
struct SemaCompleteInput {
|
|
|
|
PathRef FileName;
|
|
|
|
const tooling::CompileCommand &Command;
|
|
|
|
PrecompiledPreamble const *Preamble;
|
|
|
|
StringRef Contents;
|
|
|
|
Position Pos;
|
|
|
|
IntrusiveRefCntPtr<vfs::FileSystem> VFS;
|
|
|
|
std::shared_ptr<PCHContainerOperations> PCHs;
|
|
|
|
};
|
|
|
|
|
|
|
|
// Invokes Sema code completion on a file.
|
2018-07-03 16:09:29 +08:00
|
|
|
// If \p Includes is set, it will be updated based on the compiler invocation.
|
[clangd] Pass Context implicitly using TLS.
Summary:
Instead of passing Context explicitly around, we now have a thread-local
Context object `Context::current()` which is an implicit argument to
every function.
Most manipulation of this should use the WithContextValue helper, which
augments the current Context to add a single KV pair, and restores the
old context on destruction.
Advantages are:
- less boilerplate in functions that just propagate contexts
- reading most code doesn't require understanding context at all, and
using context as values in fewer places still
- fewer options to pass the "wrong" context when it changes within a
scope (e.g. when using Span)
- contexts pass through interfaces we can't modify, such as VFS
- propagating contexts across threads was slightly tricky (e.g.
copy vs move, no move-init in lambdas), and is now encapsulated in
the threadpool
Disadvantages are all the usual TLS stuff - hidden magic, and
potential for higher memory usage on threads that don't use the
context. (In practice, it's just one pointer)
Reviewers: ilya-biryukov
Subscribers: klimek, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D42517
llvm-svn: 323872
2018-01-31 21:40:48 +08:00
|
|
|
bool semaCodeComplete(std::unique_ptr<CodeCompleteConsumer> Consumer,
|
2018-01-19 22:34:02 +08:00
|
|
|
const clang::CodeCompleteOptions &Options,
|
2018-05-15 23:29:32 +08:00
|
|
|
const SemaCompleteInput &Input,
|
2018-07-03 16:09:29 +08:00
|
|
|
IncludeStructure *Includes = nullptr) {
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
trace::Span Tracer("Sema completion");
|
2017-12-04 21:49:59 +08:00
|
|
|
std::vector<const char *> ArgStrs;
|
2018-01-19 22:34:02 +08:00
|
|
|
for (const auto &S : Input.Command.CommandLine)
|
2017-12-04 21:49:59 +08:00
|
|
|
ArgStrs.push_back(S.c_str());
|
|
|
|
|
2018-02-14 01:15:06 +08:00
|
|
|
if (Input.VFS->setCurrentWorkingDirectory(Input.Command.Directory)) {
|
|
|
|
log("Couldn't set working directory");
|
|
|
|
// We run parsing anyway, our lit-tests rely on results for non-existing
|
|
|
|
// working dirs.
|
|
|
|
}
|
2017-12-04 21:49:59 +08:00
|
|
|
|
|
|
|
IgnoreDiagnostics DummyDiagsConsumer;
|
|
|
|
auto CI = createInvocationFromCommandLine(
|
|
|
|
ArgStrs,
|
|
|
|
CompilerInstance::createDiagnostics(new DiagnosticOptions,
|
|
|
|
&DummyDiagsConsumer, false),
|
2018-01-19 22:34:02 +08:00
|
|
|
Input.VFS);
|
2018-02-09 21:51:57 +08:00
|
|
|
if (!CI) {
|
[clangd] Upgrade logging facilities with levels and formatv.
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
2018-07-11 18:35:11 +08:00
|
|
|
elog("Couldn't create CompilerInvocation");
|
2018-02-09 21:51:57 +08:00
|
|
|
return false;
|
|
|
|
}
|
2018-05-28 20:11:37 +08:00
|
|
|
auto &FrontendOpts = CI->getFrontendOpts();
|
|
|
|
FrontendOpts.DisableFree = false;
|
|
|
|
FrontendOpts.SkipFunctionBodies = true;
|
2018-05-16 20:32:49 +08:00
|
|
|
CI->getLangOpts()->CommentOpts.ParseAllComments = true;
|
2018-01-25 17:44:06 +08:00
|
|
|
// Disable typo correction in Sema.
|
2018-05-28 20:11:37 +08:00
|
|
|
CI->getLangOpts()->SpellChecking = false;
|
|
|
|
// Setup code completion.
|
2017-12-04 21:49:59 +08:00
|
|
|
FrontendOpts.CodeCompleteOpts = Options;
|
2018-01-19 22:34:02 +08:00
|
|
|
FrontendOpts.CodeCompletionAt.FileName = Input.FileName;
|
[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
|
|
|
auto Offset = positionToOffset(Input.Contents, Input.Pos);
|
|
|
|
if (!Offset) {
|
[clangd] Upgrade logging facilities with levels and formatv.
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
2018-07-11 18:35:11 +08:00
|
|
|
elog("Code completion position was invalid {0}", Offset.takeError());
|
[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
|
|
|
return false;
|
|
|
|
}
|
|
|
|
std::tie(FrontendOpts.CodeCompletionAt.Line,
|
|
|
|
FrontendOpts.CodeCompletionAt.Column) =
|
|
|
|
offsetToClangLineColumn(Input.Contents, *Offset);
|
2017-12-04 21:49:59 +08:00
|
|
|
|
2018-05-28 20:11:37 +08:00
|
|
|
std::unique_ptr<llvm::MemoryBuffer> ContentsBuffer =
|
|
|
|
llvm::MemoryBuffer::getMemBufferCopy(Input.Contents, Input.FileName);
|
|
|
|
// The diagnostic options must be set before creating a CompilerInstance.
|
|
|
|
CI->getDiagnosticOpts().IgnoreWarnings = true;
|
|
|
|
// We reuse the preamble whether it's valid or not. This is a
|
|
|
|
// correctness/performance tradeoff: building without a preamble is slow, and
|
|
|
|
// completion is latency-sensitive.
|
|
|
|
// NOTE: we must call BeginSourceFile after prepareCompilerInstance. Otherwise
|
|
|
|
// the remapped buffers do not get freed.
|
|
|
|
auto Clang = prepareCompilerInstance(
|
|
|
|
std::move(CI), Input.Preamble, std::move(ContentsBuffer),
|
|
|
|
std::move(Input.PCHs), std::move(Input.VFS), DummyDiagsConsumer);
|
2017-12-04 21:49:59 +08:00
|
|
|
Clang->setCodeCompletionConsumer(Consumer.release());
|
|
|
|
|
|
|
|
SyntaxOnlyAction Action;
|
|
|
|
if (!Action.BeginSourceFile(*Clang, Clang->getFrontendOpts().Inputs[0])) {
|
[clangd] Upgrade logging facilities with levels and formatv.
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
2018-07-11 18:35:11 +08:00
|
|
|
log("BeginSourceFile() failed when running codeComplete for {0}",
|
[clangd] Pass Context implicitly using TLS.
Summary:
Instead of passing Context explicitly around, we now have a thread-local
Context object `Context::current()` which is an implicit argument to
every function.
Most manipulation of this should use the WithContextValue helper, which
augments the current Context to add a single KV pair, and restores the
old context on destruction.
Advantages are:
- less boilerplate in functions that just propagate contexts
- reading most code doesn't require understanding context at all, and
using context as values in fewer places still
- fewer options to pass the "wrong" context when it changes within a
scope (e.g. when using Span)
- contexts pass through interfaces we can't modify, such as VFS
- propagating contexts across threads was slightly tricky (e.g.
copy vs move, no move-init in lambdas), and is now encapsulated in
the threadpool
Disadvantages are all the usual TLS stuff - hidden magic, and
potential for higher memory usage on threads that don't use the
context. (In practice, it's just one pointer)
Reviewers: ilya-biryukov
Subscribers: klimek, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D42517
llvm-svn: 323872
2018-01-31 21:40:48 +08:00
|
|
|
Input.FileName);
|
2017-12-04 21:49:59 +08:00
|
|
|
return false;
|
|
|
|
}
|
2018-07-03 16:09:29 +08:00
|
|
|
if (Includes)
|
|
|
|
Clang->getPreprocessor().addPPCallbacks(
|
|
|
|
collectIncludeStructureCallback(Clang->getSourceManager(), Includes));
|
2017-12-04 21:49:59 +08:00
|
|
|
if (!Action.Execute()) {
|
[clangd] Upgrade logging facilities with levels and formatv.
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
2018-07-11 18:35:11 +08:00
|
|
|
log("Execute() failed when running codeComplete for {0}", Input.FileName);
|
2017-12-04 21:49:59 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
Action.EndSourceFile();
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2018-05-14 18:50:04 +08:00
|
|
|
// Should we allow index completions in the specified context?
|
|
|
|
bool allowIndex(CodeCompletionContext &CC) {
|
|
|
|
if (!contextAllowsIndex(CC.getKind()))
|
|
|
|
return false;
|
|
|
|
// We also avoid ClassName::bar (but allow namespace::bar).
|
|
|
|
auto Scope = CC.getCXXScopeSpecifier();
|
|
|
|
if (!Scope)
|
|
|
|
return true;
|
|
|
|
NestedNameSpecifier *NameSpec = (*Scope)->getScopeRep();
|
|
|
|
if (!NameSpec)
|
|
|
|
return true;
|
|
|
|
// We only query the index when qualifier is a namespace.
|
|
|
|
// If it's a class, we rely solely on sema completions.
|
|
|
|
switch (NameSpec->getKind()) {
|
|
|
|
case NestedNameSpecifier::Global:
|
|
|
|
case NestedNameSpecifier::Namespace:
|
|
|
|
case NestedNameSpecifier::NamespaceAlias:
|
|
|
|
return true;
|
|
|
|
case NestedNameSpecifier::Super:
|
|
|
|
case NestedNameSpecifier::TypeSpec:
|
|
|
|
case NestedNameSpecifier::TypeSpecWithTemplate:
|
|
|
|
// Unresolved inside a template.
|
|
|
|
case NestedNameSpecifier::Identifier:
|
|
|
|
return false;
|
|
|
|
}
|
2018-05-14 19:47:30 +08:00
|
|
|
llvm_unreachable("invalid NestedNameSpecifier kind");
|
2018-05-14 18:50:04 +08:00
|
|
|
}
|
|
|
|
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
std::future<SymbolSlab> startAsyncFuzzyFind(const SymbolIndex &Index,
|
|
|
|
const FuzzyFindRequest &Req) {
|
|
|
|
return runAsync<SymbolSlab>([&Index, Req]() {
|
|
|
|
trace::Span Tracer("Async fuzzyFind");
|
|
|
|
SymbolSlab::Builder Syms;
|
|
|
|
Index.fuzzyFind(Req, [&Syms](const Symbol &Sym) { Syms.insert(Sym); });
|
|
|
|
return std::move(Syms).build();
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
// Creates a `FuzzyFindRequest` based on the cached index request from the
|
|
|
|
// last completion, if any, and the speculated completion filter text in the
|
|
|
|
// source code.
|
|
|
|
llvm::Optional<FuzzyFindRequest> speculativeFuzzyFindRequestForCompletion(
|
|
|
|
FuzzyFindRequest CachedReq, PathRef File, StringRef Content, Position Pos) {
|
|
|
|
auto Filter = speculateCompletionFilter(Content, Pos);
|
|
|
|
if (!Filter) {
|
|
|
|
elog("Failed to speculate filter text for code completion at Pos "
|
|
|
|
"{0}:{1}: {2}",
|
|
|
|
Pos.line, Pos.character, Filter.takeError());
|
|
|
|
return llvm::None;
|
|
|
|
}
|
|
|
|
CachedReq.Query = *Filter;
|
|
|
|
return CachedReq;
|
|
|
|
}
|
|
|
|
|
2017-12-04 21:49:59 +08:00
|
|
|
} // namespace
|
|
|
|
|
|
|
|
clang::CodeCompleteOptions CodeCompleteOptions::getClangCompleteOpts() const {
|
|
|
|
clang::CodeCompleteOptions Result;
|
|
|
|
Result.IncludeCodePatterns = EnableSnippets && IncludeCodePatterns;
|
|
|
|
Result.IncludeMacros = IncludeMacros;
|
2018-01-18 23:31:30 +08:00
|
|
|
Result.IncludeGlobals = true;
|
2018-05-16 20:32:44 +08:00
|
|
|
// We choose to include full comments and not do doxygen parsing in
|
|
|
|
// completion.
|
|
|
|
// FIXME: ideally, we should support doxygen in some form, e.g. do markdown
|
|
|
|
// formatting of the comments.
|
|
|
|
Result.IncludeBriefComments = false;
|
2017-12-04 21:49:59 +08:00
|
|
|
|
2018-01-13 02:30:08 +08:00
|
|
|
// When an is used, Sema is responsible for completing the main file,
|
|
|
|
// the index can provide results from the preamble.
|
|
|
|
// Tell Sema not to deserialize the preamble to look for results.
|
|
|
|
Result.LoadExternal = !Index;
|
2018-08-08 16:59:29 +08:00
|
|
|
Result.IncludeFixIts = IncludeFixIts;
|
2017-12-20 00:50:37 +08:00
|
|
|
|
2017-12-04 21:49:59 +08:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
// Returns the most popular include header for \p Sym. If two headers are
|
|
|
|
// equally popular, prefer the shorter one. Returns empty string if \p Sym has
|
|
|
|
// no include header.
|
|
|
|
llvm::SmallVector<StringRef, 1>
|
|
|
|
getRankedIncludes(const Symbol &Sym) {
|
|
|
|
auto Includes = Sym.IncludeHeaders;
|
|
|
|
// Sort in descending order by reference count and header length.
|
|
|
|
std::sort(Includes.begin(), Includes.end(),
|
|
|
|
[](const Symbol::IncludeHeaderWithReferences &LHS,
|
|
|
|
const Symbol::IncludeHeaderWithReferences &RHS) {
|
|
|
|
if (LHS.References == RHS.References)
|
|
|
|
return LHS.IncludeHeader.size() < RHS.IncludeHeader.size();
|
|
|
|
return LHS.References > RHS.References;
|
|
|
|
});
|
|
|
|
llvm::SmallVector<StringRef, 1> Headers;
|
|
|
|
for (const auto &Include : Includes)
|
|
|
|
Headers.push_back(Include.IncludeHeader);
|
|
|
|
return Headers;
|
|
|
|
}
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// Runs Sema-based (AST) and Index-based completion, returns merged results.
|
|
|
|
//
|
|
|
|
// There are a few tricky considerations:
|
|
|
|
// - the AST provides information needed for the index query (e.g. which
|
|
|
|
// namespaces to search in). So Sema must start first.
|
|
|
|
// - we only want to return the top results (Opts.Limit).
|
|
|
|
// Building CompletionItems for everything else is wasteful, so we want to
|
|
|
|
// preserve the "native" format until we're done with scoring.
|
|
|
|
// - the data underlying Sema completion items is owned by the AST and various
|
|
|
|
// other arenas, which must stay alive for us to build CompletionItems.
|
|
|
|
// - we may get duplicate results from Sema and the Index, we need to merge.
|
|
|
|
//
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
// So we start Sema completion first, and do all our work in its callback.
|
2018-01-19 22:34:02 +08:00
|
|
|
// We use the Sema context information to query the index.
|
|
|
|
// Then we merge the two result sets, producing items that are Sema/Index/Both.
|
|
|
|
// These items are scored, and the top N are synthesized into the LSP response.
|
|
|
|
// Finally, we can clean up the data structures created by Sema completion.
|
|
|
|
//
|
|
|
|
// Main collaborators are:
|
|
|
|
// - semaCodeComplete sets up the compiler machinery to run code completion.
|
|
|
|
// - CompletionRecorder captures Sema completion results, including context.
|
|
|
|
// - SymbolIndex (Opts.Index) provides index completion results as Symbols
|
|
|
|
// - CompletionCandidates are the result of merging Sema and Index results.
|
|
|
|
// Each candidate points to an underlying CodeCompletionResult (Sema), a
|
|
|
|
// Symbol (Index), or both. It computes the result quality score.
|
|
|
|
// CompletionCandidate also does conversion to CompletionItem (at the end).
|
|
|
|
// - FuzzyMatcher scores how the candidate matches the partial identifier.
|
|
|
|
// This score is combined with the result quality score for the final score.
|
|
|
|
// - TopN determines the results with the best score.
|
|
|
|
class CodeCompleteFlow {
|
2018-02-16 22:15:55 +08:00
|
|
|
PathRef FileName;
|
2018-07-03 16:09:29 +08:00
|
|
|
IncludeStructure Includes; // Complete once the compiler runs.
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
SpeculativeFuzzyFind *SpecFuzzyFind; // Can be nullptr.
|
2018-01-19 22:34:02 +08:00
|
|
|
const CodeCompleteOptions &Opts;
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// Sema takes ownership of Recorder. Recorder is valid until Sema cleanup.
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
CompletionRecorder *Recorder = nullptr;
|
2018-01-19 22:34:02 +08:00
|
|
|
int NSema = 0, NIndex = 0, NBoth = 0; // Counters for logging.
|
|
|
|
bool Incomplete = false; // Would more be available with a higher limit?
|
2018-05-15 23:29:32 +08:00
|
|
|
llvm::Optional<FuzzyMatcher> Filter; // Initialized once Sema runs.
|
2018-07-05 16:29:33 +08:00
|
|
|
std::vector<std::string> QueryScopes; // Initialized once Sema runs.
|
2018-07-03 16:09:29 +08:00
|
|
|
// Include-insertion and proximity scoring rely on the include structure.
|
|
|
|
// This is available after Sema has run.
|
|
|
|
llvm::Optional<IncludeInserter> Inserter; // Available during runWithSema.
|
|
|
|
llvm::Optional<URIDistance> FileProximity; // Initialized once Sema runs.
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
/// Speculative request based on the cached request and the filter text before
|
|
|
|
/// the cursor.
|
|
|
|
/// Initialized right before sema run. This is only set if `SpecFuzzyFind` is
|
|
|
|
/// set and contains a cached request.
|
|
|
|
llvm::Optional<FuzzyFindRequest> SpecReq;
|
2018-01-19 22:34:02 +08:00
|
|
|
|
|
|
|
public:
|
|
|
|
// A CodeCompleteFlow object is only useful for calling run() exactly once.
|
2018-07-03 16:09:29 +08:00
|
|
|
CodeCompleteFlow(PathRef FileName, const IncludeStructure &Includes,
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
SpeculativeFuzzyFind *SpecFuzzyFind,
|
2018-07-03 16:09:29 +08:00
|
|
|
const CodeCompleteOptions &Opts)
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
: FileName(FileName), Includes(Includes), SpecFuzzyFind(SpecFuzzyFind),
|
|
|
|
Opts(Opts) {}
|
2018-01-19 22:34:02 +08:00
|
|
|
|
2018-06-29 22:47:57 +08:00
|
|
|
CodeCompleteResult run(const SemaCompleteInput &SemaCCInput) && {
|
[clangd] Pass Context implicitly using TLS.
Summary:
Instead of passing Context explicitly around, we now have a thread-local
Context object `Context::current()` which is an implicit argument to
every function.
Most manipulation of this should use the WithContextValue helper, which
augments the current Context to add a single KV pair, and restores the
old context on destruction.
Advantages are:
- less boilerplate in functions that just propagate contexts
- reading most code doesn't require understanding context at all, and
using context as values in fewer places still
- fewer options to pass the "wrong" context when it changes within a
scope (e.g. when using Span)
- contexts pass through interfaces we can't modify, such as VFS
- propagating contexts across threads was slightly tricky (e.g.
copy vs move, no move-init in lambdas), and is now encapsulated in
the threadpool
Disadvantages are all the usual TLS stuff - hidden magic, and
potential for higher memory usage on threads that don't use the
context. (In practice, it's just one pointer)
Reviewers: ilya-biryukov
Subscribers: klimek, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D42517
llvm-svn: 323872
2018-01-31 21:40:48 +08:00
|
|
|
trace::Span Tracer("CodeCompleteFlow");
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
if (Opts.Index && SpecFuzzyFind && SpecFuzzyFind->CachedReq.hasValue()) {
|
|
|
|
assert(!SpecFuzzyFind->Result.valid());
|
|
|
|
if ((SpecReq = speculativeFuzzyFindRequestForCompletion(
|
|
|
|
*SpecFuzzyFind->CachedReq, SemaCCInput.FileName,
|
|
|
|
SemaCCInput.Contents, SemaCCInput.Pos)))
|
|
|
|
SpecFuzzyFind->Result = startAsyncFuzzyFind(*Opts.Index, *SpecReq);
|
|
|
|
}
|
2018-05-15 23:29:32 +08:00
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// We run Sema code completion first. It builds an AST and calculates:
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
// - completion results based on the AST.
|
2018-01-19 22:34:02 +08:00
|
|
|
// - partial identifier and context. We need these for the index query.
|
2018-06-29 22:47:57 +08:00
|
|
|
CodeCompleteResult Output;
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
auto RecorderOwner = llvm::make_unique<CompletionRecorder>(Opts, [&]() {
|
|
|
|
assert(Recorder && "Recorder is not set");
|
2018-07-03 16:09:29 +08:00
|
|
|
auto Style =
|
2018-07-03 22:51:23 +08:00
|
|
|
format::getStyle(format::DefaultFormatStyle, SemaCCInput.FileName,
|
|
|
|
format::DefaultFallbackStyle, SemaCCInput.Contents,
|
|
|
|
SemaCCInput.VFS.get());
|
2018-07-03 16:09:29 +08:00
|
|
|
if (!Style) {
|
[clangd] Upgrade logging facilities with levels and formatv.
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
2018-07-11 18:35:11 +08:00
|
|
|
log("getStyle() failed for file {0}: {1}. Fallback is LLVM style.",
|
|
|
|
SemaCCInput.FileName, Style.takeError());
|
2018-07-03 16:09:29 +08:00
|
|
|
Style = format::getLLVMStyle();
|
|
|
|
}
|
2018-05-15 23:29:32 +08:00
|
|
|
// If preprocessor was run, inclusions from preprocessor callback should
|
2018-07-03 16:09:29 +08:00
|
|
|
// already be added to Includes.
|
|
|
|
Inserter.emplace(
|
|
|
|
SemaCCInput.FileName, SemaCCInput.Contents, *Style,
|
|
|
|
SemaCCInput.Command.Directory,
|
|
|
|
Recorder->CCSema->getPreprocessor().getHeaderSearchInfo());
|
|
|
|
for (const auto &Inc : Includes.MainFileIncludes)
|
|
|
|
Inserter->addExisting(Inc);
|
|
|
|
|
|
|
|
// Most of the cost of file proximity is in initializing the FileDistance
|
|
|
|
// structures based on the observed includes, once per query. Conceptually
|
|
|
|
// that happens here (though the per-URI-scheme initialization is lazy).
|
|
|
|
// The per-result proximity scoring is (amortized) very cheap.
|
|
|
|
FileDistanceOptions ProxOpts{}; // Use defaults.
|
|
|
|
const auto &SM = Recorder->CCSema->getSourceManager();
|
|
|
|
llvm::StringMap<SourceParams> ProxSources;
|
|
|
|
for (auto &Entry : Includes.includeDepth(
|
|
|
|
SM.getFileEntryForID(SM.getMainFileID())->getName())) {
|
|
|
|
auto &Source = ProxSources[Entry.getKey()];
|
|
|
|
Source.Cost = Entry.getValue() * ProxOpts.IncludeCost;
|
|
|
|
// Symbols near our transitive includes are good, but only consider
|
|
|
|
// things in the same directory or below it. Otherwise there can be
|
|
|
|
// many false positives.
|
|
|
|
if (Entry.getValue() > 0)
|
|
|
|
Source.MaxUpTraversals = 1;
|
|
|
|
}
|
|
|
|
FileProximity.emplace(ProxSources, ProxOpts);
|
|
|
|
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
Output = runWithSema();
|
2018-07-03 16:09:29 +08:00
|
|
|
Inserter.reset(); // Make sure this doesn't out-live Clang.
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
SPAN_ATTACH(Tracer, "sema_completion_kind",
|
|
|
|
getCompletionKindString(Recorder->CCContext.getKind()));
|
[clangd] Upgrade logging facilities with levels and formatv.
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
2018-07-11 18:35:11 +08:00
|
|
|
log("Code complete: sema context {0}, query scopes [{1}]",
|
2018-07-05 16:29:33 +08:00
|
|
|
getCompletionKindString(Recorder->CCContext.getKind()),
|
[clangd] Upgrade logging facilities with levels and formatv.
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
2018-07-11 18:35:11 +08:00
|
|
|
llvm::join(QueryScopes.begin(), QueryScopes.end(), ","));
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
});
|
|
|
|
|
|
|
|
Recorder = RecorderOwner.get();
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
|
[clangd] Pass Context implicitly using TLS.
Summary:
Instead of passing Context explicitly around, we now have a thread-local
Context object `Context::current()` which is an implicit argument to
every function.
Most manipulation of this should use the WithContextValue helper, which
augments the current Context to add a single KV pair, and restores the
old context on destruction.
Advantages are:
- less boilerplate in functions that just propagate contexts
- reading most code doesn't require understanding context at all, and
using context as values in fewer places still
- fewer options to pass the "wrong" context when it changes within a
scope (e.g. when using Span)
- contexts pass through interfaces we can't modify, such as VFS
- propagating contexts across threads was slightly tricky (e.g.
copy vs move, no move-init in lambdas), and is now encapsulated in
the threadpool
Disadvantages are all the usual TLS stuff - hidden magic, and
potential for higher memory usage on threads that don't use the
context. (In practice, it's just one pointer)
Reviewers: ilya-biryukov
Subscribers: klimek, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D42517
llvm-svn: 323872
2018-01-31 21:40:48 +08:00
|
|
|
semaCodeComplete(std::move(RecorderOwner), Opts.getClangCompleteOpts(),
|
2018-05-15 23:29:32 +08:00
|
|
|
SemaCCInput, &Includes);
|
2018-01-19 22:34:02 +08:00
|
|
|
|
2018-01-31 01:20:54 +08:00
|
|
|
SPAN_ATTACH(Tracer, "sema_results", NSema);
|
|
|
|
SPAN_ATTACH(Tracer, "index_results", NIndex);
|
|
|
|
SPAN_ATTACH(Tracer, "merged_results", NBoth);
|
2018-07-09 22:25:59 +08:00
|
|
|
SPAN_ATTACH(Tracer, "returned_results", int64_t(Output.Completions.size()));
|
2018-06-29 22:47:57 +08:00
|
|
|
SPAN_ATTACH(Tracer, "incomplete", Output.HasMore);
|
[clangd] Upgrade logging facilities with levels and formatv.
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
2018-07-11 18:35:11 +08:00
|
|
|
log("Code complete: {0} results from Sema, {1} from Index, "
|
|
|
|
"{2} matched, {3} returned{4}.",
|
|
|
|
NSema, NIndex, NBoth, Output.Completions.size(),
|
|
|
|
Output.HasMore ? " (incomplete)" : "");
|
2018-06-29 22:47:57 +08:00
|
|
|
assert(!Opts.Limit || Output.Completions.size() <= Opts.Limit);
|
2018-01-19 22:34:02 +08:00
|
|
|
// We don't assert that isIncomplete means we hit a limit.
|
|
|
|
// Indexes may choose to impose their own limits even if we don't have one.
|
|
|
|
return Output;
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
// This is called by run() once Sema code completion is done, but before the
|
|
|
|
// Sema data structures are torn down. It does all the real work.
|
2018-06-29 22:47:57 +08:00
|
|
|
CodeCompleteResult runWithSema() {
|
2018-08-13 16:23:01 +08:00
|
|
|
const auto &CodeCompletionRange = CharSourceRange::getCharRange(
|
|
|
|
Recorder->CCSema->getPreprocessor().getCodeCompletionTokenRange());
|
|
|
|
Range TextEditRange;
|
|
|
|
// When we are getting completions with an empty identifier, for example
|
|
|
|
// std::vector<int> asdf;
|
|
|
|
// asdf.^;
|
|
|
|
// Then the range will be invalid and we will be doing insertion, use
|
|
|
|
// current cursor position in such cases as range.
|
|
|
|
if (CodeCompletionRange.isValid()) {
|
|
|
|
TextEditRange = halfOpenToRange(Recorder->CCSema->getSourceManager(),
|
|
|
|
CodeCompletionRange);
|
|
|
|
} else {
|
|
|
|
const auto &Pos = sourceLocToPosition(
|
|
|
|
Recorder->CCSema->getSourceManager(),
|
|
|
|
Recorder->CCSema->getPreprocessor().getCodeCompletionLoc());
|
|
|
|
TextEditRange.start = TextEditRange.end = Pos;
|
|
|
|
}
|
2018-01-19 22:34:02 +08:00
|
|
|
Filter = FuzzyMatcher(
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
Recorder->CCSema->getPreprocessor().getCodeCompletionFilter());
|
2018-07-05 16:29:33 +08:00
|
|
|
QueryScopes = getQueryScopes(Recorder->CCContext,
|
|
|
|
Recorder->CCSema->getSourceManager());
|
2018-01-19 22:34:02 +08:00
|
|
|
// Sema provides the needed context to query the index.
|
|
|
|
// FIXME: in addition to querying for extra/overlapping symbols, we should
|
|
|
|
// explicitly request symbols corresponding to Sema results.
|
|
|
|
// We can use their signals even if the index can't suggest them.
|
|
|
|
// We must copy index results to preserve them, but there are at most Limit.
|
2018-06-15 21:34:18 +08:00
|
|
|
auto IndexResults = (Opts.Index && allowIndex(Recorder->CCContext))
|
|
|
|
? queryIndex()
|
|
|
|
: SymbolSlab();
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
trace::Span Tracer("Populate CodeCompleteResult");
|
2018-08-23 21:14:50 +08:00
|
|
|
// Merge Sema, Index and Override results, score them, and pick the
|
|
|
|
// winners.
|
|
|
|
const auto Overrides = getNonOverridenMethodCompletionResults(
|
|
|
|
Recorder->CCSema->CurContext, Recorder->CCSema);
|
|
|
|
auto Top = mergeResults(Recorder->Results, IndexResults, Overrides);
|
2018-06-29 22:47:57 +08:00
|
|
|
CodeCompleteResult Output;
|
2018-08-23 21:14:50 +08:00
|
|
|
|
|
|
|
// Convert the results to final form, assembling the expensive strings.
|
2018-06-29 22:47:57 +08:00
|
|
|
for (auto &C : Top) {
|
|
|
|
Output.Completions.push_back(toCodeCompletion(C.first));
|
|
|
|
Output.Completions.back().Score = C.second;
|
2018-08-13 16:23:01 +08:00
|
|
|
Output.Completions.back().CompletionTokenRange = TextEditRange;
|
2018-06-29 22:47:57 +08:00
|
|
|
}
|
|
|
|
Output.HasMore = Incomplete;
|
2018-07-23 18:56:37 +08:00
|
|
|
Output.Context = Recorder->CCContext.getKind();
|
2018-08-23 21:14:50 +08:00
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
return Output;
|
|
|
|
}
|
|
|
|
|
|
|
|
SymbolSlab queryIndex() {
|
[clangd] Pass Context implicitly using TLS.
Summary:
Instead of passing Context explicitly around, we now have a thread-local
Context object `Context::current()` which is an implicit argument to
every function.
Most manipulation of this should use the WithContextValue helper, which
augments the current Context to add a single KV pair, and restores the
old context on destruction.
Advantages are:
- less boilerplate in functions that just propagate contexts
- reading most code doesn't require understanding context at all, and
using context as values in fewer places still
- fewer options to pass the "wrong" context when it changes within a
scope (e.g. when using Span)
- contexts pass through interfaces we can't modify, such as VFS
- propagating contexts across threads was slightly tricky (e.g.
copy vs move, no move-init in lambdas), and is now encapsulated in
the threadpool
Disadvantages are all the usual TLS stuff - hidden magic, and
potential for higher memory usage on threads that don't use the
context. (In practice, it's just one pointer)
Reviewers: ilya-biryukov
Subscribers: klimek, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D42517
llvm-svn: 323872
2018-01-31 21:40:48 +08:00
|
|
|
trace::Span Tracer("Query index");
|
2018-07-09 22:25:59 +08:00
|
|
|
SPAN_ATTACH(Tracer, "limit", int64_t(Opts.Limit));
|
2018-01-31 01:20:54 +08:00
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// Build the query.
|
|
|
|
FuzzyFindRequest Req;
|
2018-01-25 17:20:09 +08:00
|
|
|
if (Opts.Limit)
|
|
|
|
Req.MaxCandidateCount = Opts.Limit;
|
2018-01-19 22:34:02 +08:00
|
|
|
Req.Query = Filter->pattern();
|
[clangd] Add "member" symbols to the index
Summary:
This adds more symbols to the index:
- member variables and functions
- enum constants in scoped enums
The code completion behavior should remain intact but workspace symbols should
now provide much more useful symbols.
Other symbols should be considered such as the ones in "main files" (files not
being included) but this can be done separately as this introduces its fair
share of problems.
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewers: ioeric, sammccall
Reviewed By: ioeric, sammccall
Subscribers: hokein, sammccall, jkorous, klimek, ilya-biryukov, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44954
llvm-svn: 334017
2018-06-05 22:01:40 +08:00
|
|
|
Req.RestrictForCodeCompletion = true;
|
2018-07-05 16:29:33 +08:00
|
|
|
Req.Scopes = QueryScopes;
|
2018-07-03 16:09:29 +08:00
|
|
|
// FIXME: we should send multiple weighted paths here.
|
2018-06-12 16:48:20 +08:00
|
|
|
Req.ProximityPaths.push_back(FileName);
|
[clangd] Upgrade logging facilities with levels and formatv.
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
2018-07-11 18:35:11 +08:00
|
|
|
vlog("Code complete: fuzzyFind(\"{0}\", scopes=[{1}])", Req.Query,
|
|
|
|
llvm::join(Req.Scopes.begin(), Req.Scopes.end(), ","));
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
|
|
|
|
if (SpecFuzzyFind)
|
|
|
|
SpecFuzzyFind->NewReq = Req;
|
|
|
|
if (SpecFuzzyFind && SpecFuzzyFind->Result.valid() && (*SpecReq == Req)) {
|
|
|
|
vlog("Code complete: speculative fuzzy request matches the actual index "
|
|
|
|
"request. Waiting for the speculative index results.");
|
|
|
|
SPAN_ATTACH(Tracer, "Speculative results", true);
|
|
|
|
|
|
|
|
trace::Span WaitSpec("Wait speculative results");
|
|
|
|
return SpecFuzzyFind->Result.get();
|
|
|
|
}
|
|
|
|
|
|
|
|
SPAN_ATTACH(Tracer, "Speculative results", false);
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// Run the query against the index.
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
SymbolSlab::Builder ResultsBuilder;
|
2018-02-19 21:04:41 +08:00
|
|
|
if (Opts.Index->fuzzyFind(
|
|
|
|
Req, [&](const Symbol &Sym) { ResultsBuilder.insert(Sym); }))
|
|
|
|
Incomplete = true;
|
2018-01-19 22:34:02 +08:00
|
|
|
return std::move(ResultsBuilder).build();
|
|
|
|
}
|
|
|
|
|
2018-08-23 21:14:50 +08:00
|
|
|
// Merges Sema, Index and Override results where possible, to form
|
|
|
|
// CompletionCandidates. Groups overloads if desired, to form
|
|
|
|
// CompletionCandidate::Bundles. The bundles are scored and top results are
|
|
|
|
// returned, best to worst.
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
std::vector<ScoredBundle>
|
2018-08-23 21:14:50 +08:00
|
|
|
mergeResults(const std::vector<CodeCompletionResult> &SemaResults,
|
|
|
|
const SymbolSlab &IndexResults,
|
|
|
|
const std::vector<CodeCompletionResult> &OverrideResults) {
|
[clangd] Pass Context implicitly using TLS.
Summary:
Instead of passing Context explicitly around, we now have a thread-local
Context object `Context::current()` which is an implicit argument to
every function.
Most manipulation of this should use the WithContextValue helper, which
augments the current Context to add a single KV pair, and restores the
old context on destruction.
Advantages are:
- less boilerplate in functions that just propagate contexts
- reading most code doesn't require understanding context at all, and
using context as values in fewer places still
- fewer options to pass the "wrong" context when it changes within a
scope (e.g. when using Span)
- contexts pass through interfaces we can't modify, such as VFS
- propagating contexts across threads was slightly tricky (e.g.
copy vs move, no move-init in lambdas), and is now encapsulated in
the threadpool
Disadvantages are all the usual TLS stuff - hidden magic, and
potential for higher memory usage on threads that don't use the
context. (In practice, it's just one pointer)
Reviewers: ilya-biryukov
Subscribers: klimek, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D42517
llvm-svn: 323872
2018-01-31 21:40:48 +08:00
|
|
|
trace::Span Tracer("Merge and score results");
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
std::vector<CompletionCandidate::Bundle> Bundles;
|
|
|
|
llvm::DenseMap<size_t, size_t> BundleLookup;
|
|
|
|
auto AddToBundles = [&](const CodeCompletionResult *SemaResult,
|
2018-08-23 21:14:50 +08:00
|
|
|
const Symbol *IndexResult,
|
|
|
|
bool IsOverride = false) {
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
CompletionCandidate C;
|
|
|
|
C.SemaResult = SemaResult;
|
|
|
|
C.IndexResult = IndexResult;
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
if (C.IndexResult)
|
|
|
|
C.RankedIncludeHeaders = getRankedIncludes(*C.IndexResult);
|
2018-08-23 21:14:50 +08:00
|
|
|
C.IsOverride = IsOverride;
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
C.Name = IndexResult ? IndexResult->Name : Recorder->getName(*SemaResult);
|
|
|
|
if (auto OverloadSet = Opts.BundleOverloads ? C.overloadSet() : 0) {
|
|
|
|
auto Ret = BundleLookup.try_emplace(OverloadSet, Bundles.size());
|
|
|
|
if (Ret.second)
|
|
|
|
Bundles.emplace_back();
|
|
|
|
Bundles[Ret.first->second].push_back(std::move(C));
|
|
|
|
} else {
|
|
|
|
Bundles.emplace_back();
|
|
|
|
Bundles.back().push_back(std::move(C));
|
|
|
|
}
|
|
|
|
};
|
2018-01-19 22:34:02 +08:00
|
|
|
llvm::DenseSet<const Symbol *> UsedIndexResults;
|
|
|
|
auto CorrespondingIndexResult =
|
|
|
|
[&](const CodeCompletionResult &SemaResult) -> const Symbol * {
|
|
|
|
if (auto SymID = getSymbolID(SemaResult)) {
|
|
|
|
auto I = IndexResults.find(*SymID);
|
|
|
|
if (I != IndexResults.end()) {
|
|
|
|
UsedIndexResults.insert(&*I);
|
|
|
|
return &*I;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return nullptr;
|
|
|
|
};
|
|
|
|
// Emit all Sema results, merging them with Index results if possible.
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
for (auto &SemaResult : Recorder->Results)
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
AddToBundles(&SemaResult, CorrespondingIndexResult(SemaResult));
|
2018-08-23 21:14:50 +08:00
|
|
|
// Handle OverrideResults the same way we deal with SemaResults. Since these
|
|
|
|
// results use the same structs as a SemaResult it is safe to do that, but
|
|
|
|
// we need to make sure we dont' duplicate things in future if Sema starts
|
|
|
|
// to provide them as well.
|
|
|
|
for (auto &OverrideResult : OverrideResults)
|
|
|
|
AddToBundles(&OverrideResult, CorrespondingIndexResult(OverrideResult),
|
|
|
|
true);
|
2018-01-19 22:34:02 +08:00
|
|
|
// Now emit any Index-only results.
|
|
|
|
for (const auto &IndexResult : IndexResults) {
|
|
|
|
if (UsedIndexResults.count(&IndexResult))
|
|
|
|
continue;
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
AddToBundles(/*SemaResult=*/nullptr, &IndexResult);
|
2018-01-19 22:34:02 +08:00
|
|
|
}
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
// We only keep the best N results at any time, in "native" format.
|
|
|
|
TopN<ScoredBundle, ScoredBundleGreater> Top(
|
|
|
|
Opts.Limit == 0 ? std::numeric_limits<size_t>::max() : Opts.Limit);
|
|
|
|
for (auto &Bundle : Bundles)
|
|
|
|
addCandidate(Top, std::move(Bundle));
|
2018-01-19 22:34:02 +08:00
|
|
|
return std::move(Top).items();
|
|
|
|
}
|
|
|
|
|
2018-06-08 21:32:25 +08:00
|
|
|
Optional<float> fuzzyScore(const CompletionCandidate &C) {
|
|
|
|
// Macros can be very spammy, so we only support prefix completion.
|
|
|
|
// We won't end up with underfull index results, as macros are sema-only.
|
|
|
|
if (C.SemaResult && C.SemaResult->Kind == CodeCompletionResult::RK_Macro &&
|
|
|
|
!C.Name.startswith_lower(Filter->pattern()))
|
|
|
|
return None;
|
|
|
|
return Filter->match(C.Name);
|
|
|
|
}
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// Scores a candidate and adds it to the TopN structure.
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
void addCandidate(TopN<ScoredBundle, ScoredBundleGreater> &Candidates,
|
|
|
|
CompletionCandidate::Bundle Bundle) {
|
[clangd] Extract scoring/ranking logic, and shave yaks.
Summary:
Code completion scoring was embedded in CodeComplete.cpp, which is bad:
- awkward to test. The mechanisms (extracting info from index/sema) can be
unit-tested well, the policy (scoring) should be quantitatively measured.
Neither was easily possible, and debugging was hard.
The intermediate signal struct makes this easier.
- hard to reuse. This is a bug in workspaceSymbols: it just presents the
results in the index order, which is not sorted in practice, it needs to rank
them!
Also, index implementations care about scoring (both query-dependent and
independent) in order to truncate result lists appropriately.
The main yak shaved here is the build() function that had 3 variants across
unit tests is unified in TestTU.h (rather than adding a 4th variant).
Reviewers: ilya-biryukov
Subscribers: klimek, mgorny, ioeric, MaskRay, jkorous, mgrang, cfe-commits
Differential Revision: https://reviews.llvm.org/D46524
llvm-svn: 332378
2018-05-16 01:43:27 +08:00
|
|
|
SymbolQualitySignals Quality;
|
|
|
|
SymbolRelevanceSignals Relevance;
|
2018-07-23 18:56:37 +08:00
|
|
|
Relevance.Context = Recorder->CCContext.getKind();
|
2018-06-06 00:30:25 +08:00
|
|
|
Relevance.Query = SymbolRelevanceSignals::CodeComplete;
|
2018-07-05 16:26:53 +08:00
|
|
|
Relevance.FileProximityMatch = FileProximity.getPointer();
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
auto &First = Bundle.front();
|
|
|
|
if (auto FuzzyScore = fuzzyScore(First))
|
[clangd] Extract scoring/ranking logic, and shave yaks.
Summary:
Code completion scoring was embedded in CodeComplete.cpp, which is bad:
- awkward to test. The mechanisms (extracting info from index/sema) can be
unit-tested well, the policy (scoring) should be quantitatively measured.
Neither was easily possible, and debugging was hard.
The intermediate signal struct makes this easier.
- hard to reuse. This is a bug in workspaceSymbols: it just presents the
results in the index order, which is not sorted in practice, it needs to rank
them!
Also, index implementations care about scoring (both query-dependent and
independent) in order to truncate result lists appropriately.
The main yak shaved here is the build() function that had 3 variants across
unit tests is unified in TestTU.h (rather than adding a 4th variant).
Reviewers: ilya-biryukov
Subscribers: klimek, mgorny, ioeric, MaskRay, jkorous, mgrang, cfe-commits
Differential Revision: https://reviews.llvm.org/D46524
llvm-svn: 332378
2018-05-16 01:43:27 +08:00
|
|
|
Relevance.NameMatch = *FuzzyScore;
|
2018-01-19 22:34:02 +08:00
|
|
|
else
|
|
|
|
return;
|
2018-07-05 14:20:41 +08:00
|
|
|
SymbolOrigin Origin = SymbolOrigin::Unknown;
|
2018-07-06 19:50:49 +08:00
|
|
|
bool FromIndex = false;
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
for (const auto &Candidate : Bundle) {
|
|
|
|
if (Candidate.IndexResult) {
|
|
|
|
Quality.merge(*Candidate.IndexResult);
|
|
|
|
Relevance.merge(*Candidate.IndexResult);
|
2018-07-06 19:50:49 +08:00
|
|
|
Origin |= Candidate.IndexResult->Origin;
|
|
|
|
FromIndex = true;
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
}
|
|
|
|
if (Candidate.SemaResult) {
|
|
|
|
Quality.merge(*Candidate.SemaResult);
|
|
|
|
Relevance.merge(*Candidate.SemaResult);
|
2018-07-06 19:50:49 +08:00
|
|
|
Origin |= SymbolOrigin::AST;
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
}
|
[clangd] Extract scoring/ranking logic, and shave yaks.
Summary:
Code completion scoring was embedded in CodeComplete.cpp, which is bad:
- awkward to test. The mechanisms (extracting info from index/sema) can be
unit-tested well, the policy (scoring) should be quantitatively measured.
Neither was easily possible, and debugging was hard.
The intermediate signal struct makes this easier.
- hard to reuse. This is a bug in workspaceSymbols: it just presents the
results in the index order, which is not sorted in practice, it needs to rank
them!
Also, index implementations care about scoring (both query-dependent and
independent) in order to truncate result lists appropriately.
The main yak shaved here is the build() function that had 3 variants across
unit tests is unified in TestTU.h (rather than adding a 4th variant).
Reviewers: ilya-biryukov
Subscribers: klimek, mgorny, ioeric, MaskRay, jkorous, mgrang, cfe-commits
Differential Revision: https://reviews.llvm.org/D46524
llvm-svn: 332378
2018-05-16 01:43:27 +08:00
|
|
|
}
|
|
|
|
|
2018-06-29 22:47:57 +08:00
|
|
|
CodeCompletion::Scores Scores;
|
|
|
|
Scores.Quality = Quality.evaluate();
|
|
|
|
Scores.Relevance = Relevance.evaluate();
|
|
|
|
Scores.Total = evaluateSymbolAndRelevance(Scores.Quality, Scores.Relevance);
|
|
|
|
// NameMatch is in fact a multiplier on total score, so rescoring is sound.
|
|
|
|
Scores.ExcludingName = Relevance.NameMatch
|
|
|
|
? Scores.Total / Relevance.NameMatch
|
|
|
|
: Scores.Quality;
|
[clangd] Extract scoring/ranking logic, and shave yaks.
Summary:
Code completion scoring was embedded in CodeComplete.cpp, which is bad:
- awkward to test. The mechanisms (extracting info from index/sema) can be
unit-tested well, the policy (scoring) should be quantitatively measured.
Neither was easily possible, and debugging was hard.
The intermediate signal struct makes this easier.
- hard to reuse. This is a bug in workspaceSymbols: it just presents the
results in the index order, which is not sorted in practice, it needs to rank
them!
Also, index implementations care about scoring (both query-dependent and
independent) in order to truncate result lists appropriately.
The main yak shaved here is the build() function that had 3 variants across
unit tests is unified in TestTU.h (rather than adding a 4th variant).
Reviewers: ilya-biryukov
Subscribers: klimek, mgorny, ioeric, MaskRay, jkorous, mgrang, cfe-commits
Differential Revision: https://reviews.llvm.org/D46524
llvm-svn: 332378
2018-05-16 01:43:27 +08:00
|
|
|
|
[clangd] Upgrade logging facilities with levels and formatv.
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
2018-07-11 18:35:11 +08:00
|
|
|
dlog("CodeComplete: {0} ({1}) = {2}\n{3}{4}\n", First.Name,
|
|
|
|
llvm::to_string(Origin), Scores.Total, llvm::to_string(Quality),
|
|
|
|
llvm::to_string(Relevance));
|
2018-01-19 22:34:02 +08:00
|
|
|
|
2018-07-05 14:20:41 +08:00
|
|
|
NSema += bool(Origin & SymbolOrigin::AST);
|
2018-07-06 19:50:49 +08:00
|
|
|
NIndex += FromIndex;
|
|
|
|
NBoth += bool(Origin & SymbolOrigin::AST) && FromIndex;
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
if (Candidates.push({std::move(Bundle), Scores}))
|
2018-02-19 21:04:41 +08:00
|
|
|
Incomplete = true;
|
2018-01-19 22:34:02 +08:00
|
|
|
}
|
|
|
|
|
2018-06-29 22:47:57 +08:00
|
|
|
CodeCompletion toCodeCompletion(const CompletionCandidate::Bundle &Bundle) {
|
|
|
|
llvm::Optional<CodeCompletionBuilder> Builder;
|
|
|
|
for (const auto &Item : Bundle) {
|
|
|
|
CodeCompletionString *SemaCCS =
|
|
|
|
Item.SemaResult ? Recorder->codeCompletionString(*Item.SemaResult)
|
|
|
|
: nullptr;
|
|
|
|
if (!Builder)
|
|
|
|
Builder.emplace(Recorder->CCSema->getASTContext(), Item, SemaCCS,
|
2018-07-03 16:09:29 +08:00
|
|
|
*Inserter, FileName, Opts);
|
2018-06-29 22:47:57 +08:00
|
|
|
else
|
|
|
|
Builder->add(Item, SemaCCS);
|
2018-05-16 20:32:44 +08:00
|
|
|
}
|
2018-06-29 22:47:57 +08:00
|
|
|
return Builder->build();
|
2018-01-19 22:34:02 +08:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
llvm::Expected<llvm::StringRef>
|
|
|
|
speculateCompletionFilter(llvm::StringRef Content, Position Pos) {
|
|
|
|
auto Offset = positionToOffset(Content, Pos);
|
|
|
|
if (!Offset)
|
|
|
|
return llvm::make_error<llvm::StringError>(
|
|
|
|
"Failed to convert position to offset in content.",
|
|
|
|
llvm::inconvertibleErrorCode());
|
|
|
|
if (*Offset == 0)
|
|
|
|
return "";
|
|
|
|
|
|
|
|
// Start from the character before the cursor.
|
|
|
|
int St = *Offset - 1;
|
|
|
|
// FIXME(ioeric): consider UTF characters?
|
|
|
|
auto IsValidIdentifierChar = [](char c) {
|
|
|
|
return ((c >= 'a' && c <= 'z') || (c >= 'A' && c <= 'Z') ||
|
|
|
|
(c >= '0' && c <= '9') || (c == '_'));
|
|
|
|
};
|
|
|
|
size_t Len = 0;
|
|
|
|
for (; (St >= 0) && IsValidIdentifierChar(Content[St]); --St, ++Len) {
|
|
|
|
}
|
|
|
|
if (Len > 0)
|
|
|
|
St++; // Shift to the first valid character.
|
|
|
|
return Content.substr(St, Len);
|
|
|
|
}
|
|
|
|
|
|
|
|
CodeCompleteResult
|
|
|
|
codeComplete(PathRef FileName, const tooling::CompileCommand &Command,
|
|
|
|
PrecompiledPreamble const *Preamble,
|
|
|
|
const IncludeStructure &PreambleInclusions, StringRef Contents,
|
|
|
|
Position Pos, IntrusiveRefCntPtr<vfs::FileSystem> VFS,
|
|
|
|
std::shared_ptr<PCHContainerOperations> PCHs,
|
|
|
|
CodeCompleteOptions Opts, SpeculativeFuzzyFind *SpecFuzzyFind) {
|
|
|
|
return CodeCompleteFlow(FileName, PreambleInclusions, SpecFuzzyFind, Opts)
|
2018-07-03 16:09:29 +08:00
|
|
|
.run({FileName, Command, Preamble, Contents, Pos, VFS, PCHs});
|
2017-12-04 21:49:59 +08:00
|
|
|
}
|
|
|
|
|
[clangd] Pass Context implicitly using TLS.
Summary:
Instead of passing Context explicitly around, we now have a thread-local
Context object `Context::current()` which is an implicit argument to
every function.
Most manipulation of this should use the WithContextValue helper, which
augments the current Context to add a single KV pair, and restores the
old context on destruction.
Advantages are:
- less boilerplate in functions that just propagate contexts
- reading most code doesn't require understanding context at all, and
using context as values in fewer places still
- fewer options to pass the "wrong" context when it changes within a
scope (e.g. when using Span)
- contexts pass through interfaces we can't modify, such as VFS
- propagating contexts across threads was slightly tricky (e.g.
copy vs move, no move-init in lambdas), and is now encapsulated in
the threadpool
Disadvantages are all the usual TLS stuff - hidden magic, and
potential for higher memory usage on threads that don't use the
context. (In practice, it's just one pointer)
Reviewers: ilya-biryukov
Subscribers: klimek, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D42517
llvm-svn: 323872
2018-01-31 21:40:48 +08:00
|
|
|
SignatureHelp signatureHelp(PathRef FileName,
|
2017-12-13 20:51:22 +08:00
|
|
|
const tooling::CompileCommand &Command,
|
|
|
|
PrecompiledPreamble const *Preamble,
|
|
|
|
StringRef Contents, Position Pos,
|
|
|
|
IntrusiveRefCntPtr<vfs::FileSystem> VFS,
|
2018-08-17 17:32:30 +08:00
|
|
|
std::shared_ptr<PCHContainerOperations> PCHs,
|
|
|
|
SymbolIndex *Index) {
|
2017-12-04 21:49:59 +08:00
|
|
|
SignatureHelp Result;
|
|
|
|
clang::CodeCompleteOptions Options;
|
|
|
|
Options.IncludeGlobals = false;
|
|
|
|
Options.IncludeMacros = false;
|
|
|
|
Options.IncludeCodePatterns = false;
|
2018-05-16 20:32:44 +08:00
|
|
|
Options.IncludeBriefComments = false;
|
2018-07-03 16:09:29 +08:00
|
|
|
IncludeStructure PreambleInclusions; // Unused for signatureHelp
|
2018-08-17 17:32:30 +08:00
|
|
|
semaCodeComplete(
|
|
|
|
llvm::make_unique<SignatureHelpCollector>(Options, Index, Result),
|
|
|
|
Options,
|
|
|
|
{FileName, Command, Preamble, Contents, Pos, std::move(VFS),
|
|
|
|
std::move(PCHs)});
|
2017-12-04 21:49:59 +08:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
[clangd] Add "member" symbols to the index
Summary:
This adds more symbols to the index:
- member variables and functions
- enum constants in scoped enums
The code completion behavior should remain intact but workspace symbols should
now provide much more useful symbols.
Other symbols should be considered such as the ones in "main files" (files not
being included) but this can be done separately as this introduces its fair
share of problems.
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewers: ioeric, sammccall
Reviewed By: ioeric, sammccall
Subscribers: hokein, sammccall, jkorous, klimek, ilya-biryukov, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44954
llvm-svn: 334017
2018-06-05 22:01:40 +08:00
|
|
|
bool isIndexedForCodeCompletion(const NamedDecl &ND, ASTContext &ASTCtx) {
|
|
|
|
using namespace clang::ast_matchers;
|
|
|
|
auto InTopLevelScope = hasDeclContext(
|
|
|
|
anyOf(namespaceDecl(), translationUnitDecl(), linkageSpecDecl()));
|
|
|
|
return !match(decl(anyOf(InTopLevelScope,
|
|
|
|
hasDeclContext(
|
|
|
|
enumDecl(InTopLevelScope, unless(isScoped()))))),
|
|
|
|
ND, ASTCtx)
|
|
|
|
.empty();
|
|
|
|
}
|
|
|
|
|
2018-06-29 22:47:57 +08:00
|
|
|
CompletionItem CodeCompletion::render(const CodeCompleteOptions &Opts) const {
|
|
|
|
CompletionItem LSP;
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
const auto *InsertInclude = Includes.empty() ? nullptr : &Includes[0];
|
|
|
|
LSP.label = ((InsertInclude && InsertInclude->Insertion)
|
|
|
|
? Opts.IncludeIndicator.Insert
|
|
|
|
: Opts.IncludeIndicator.NoInsert) +
|
2018-07-05 14:20:41 +08:00
|
|
|
(Opts.ShowOrigins ? "[" + llvm::to_string(Origin) + "]" : "") +
|
2018-06-29 22:47:57 +08:00
|
|
|
RequiredQualifier + Name + Signature;
|
2018-07-05 14:20:41 +08:00
|
|
|
|
2018-06-29 22:47:57 +08:00
|
|
|
LSP.kind = Kind;
|
|
|
|
LSP.detail = BundleSize > 1 ? llvm::formatv("[{0} overloads]", BundleSize)
|
|
|
|
: ReturnType;
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
if (InsertInclude)
|
|
|
|
LSP.detail += "\n" + InsertInclude->Header;
|
2018-06-29 22:47:57 +08:00
|
|
|
LSP.documentation = Documentation;
|
|
|
|
LSP.sortText = sortText(Score.Total, Name);
|
|
|
|
LSP.filterText = Name;
|
2018-08-13 16:23:01 +08:00
|
|
|
LSP.textEdit = {CompletionTokenRange, RequiredQualifier + Name};
|
|
|
|
// Merge continious additionalTextEdits into main edit. The main motivation
|
|
|
|
// behind this is to help LSP clients, it seems most of them are confused when
|
|
|
|
// they are provided with additionalTextEdits that are consecutive to main
|
|
|
|
// edit.
|
|
|
|
// Note that we store additional text edits from back to front in a line. That
|
|
|
|
// is mainly to help LSP clients again, so that changes do not effect each
|
|
|
|
// other.
|
|
|
|
for (const auto &FixIt : FixIts) {
|
|
|
|
if (IsRangeConsecutive(FixIt.range, LSP.textEdit->range)) {
|
|
|
|
LSP.textEdit->newText = FixIt.newText + LSP.textEdit->newText;
|
|
|
|
LSP.textEdit->range.start = FixIt.range.start;
|
|
|
|
} else {
|
|
|
|
LSP.additionalTextEdits.push_back(FixIt);
|
|
|
|
}
|
|
|
|
}
|
2018-08-23 20:19:39 +08:00
|
|
|
if (Opts.EnableSnippets)
|
|
|
|
LSP.textEdit->newText += SnippetSuffix;
|
2018-08-17 23:42:54 +08:00
|
|
|
|
2018-08-13 16:23:01 +08:00
|
|
|
// FIXME(kadircet): Do not even fill insertText after making sure textEdit is
|
|
|
|
// compatible with most of the editors.
|
|
|
|
LSP.insertText = LSP.textEdit->newText;
|
2018-06-29 22:47:57 +08:00
|
|
|
LSP.insertTextFormat = Opts.EnableSnippets ? InsertTextFormat::Snippet
|
|
|
|
: InsertTextFormat::PlainText;
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
if (InsertInclude && InsertInclude->Insertion)
|
|
|
|
LSP.additionalTextEdits.push_back(*InsertInclude->Insertion);
|
2018-06-29 22:47:57 +08:00
|
|
|
return LSP;
|
|
|
|
}
|
|
|
|
|
2018-07-02 19:13:16 +08:00
|
|
|
raw_ostream &operator<<(raw_ostream &OS, const CodeCompletion &C) {
|
|
|
|
// For now just lean on CompletionItem.
|
|
|
|
return OS << C.render(CodeCompleteOptions());
|
|
|
|
}
|
|
|
|
|
|
|
|
raw_ostream &operator<<(raw_ostream &OS, const CodeCompleteResult &R) {
|
|
|
|
OS << "CodeCompleteResult: " << R.Completions.size() << (R.HasMore ? "+" : "")
|
2018-07-23 18:56:37 +08:00
|
|
|
<< " (" << getCompletionKindString(R.Context) << ")"
|
2018-07-02 19:13:16 +08:00
|
|
|
<< " items:\n";
|
|
|
|
for (const auto &C : R.Completions)
|
|
|
|
OS << C << "\n";
|
|
|
|
return OS;
|
|
|
|
}
|
|
|
|
|
2017-12-04 21:49:59 +08:00
|
|
|
} // namespace clangd
|
|
|
|
} // namespace clang
|