2018-08-15 00:03:32 +08:00
|
|
|
//===--- CodeComplete.cpp ----------------------------------------*- C++-*-===//
|
2017-12-04 21:49:59 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2017-12-04 21:49:59 +08:00
|
|
|
//
|
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-11-26 23:38:01 +08:00
|
|
|
#include "ExpectedTypes.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"
|
2019-09-04 15:35:00 +08:00
|
|
|
#include "Preamble.h"
|
2019-06-04 17:36:59 +08:00
|
|
|
#include "Protocol.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"
|
2019-09-04 21:04:34 +08:00
|
|
|
#include "TUScheduler.h"
|
2019-09-04 17:53:24 +08:00
|
|
|
#include "Threading.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"
|
2019-02-28 21:23:03 +08:00
|
|
|
#include "index/Symbol.h"
|
2019-04-11 17:36:36 +08:00
|
|
|
#include "index/SymbolOrigin.h"
|
2018-10-17 19:19:02 +08:00
|
|
|
#include "clang/AST/Decl.h"
|
|
|
|
#include "clang/AST/DeclBase.h"
|
2019-04-10 19:50:40 +08:00
|
|
|
#include "clang/Basic/CharInfo.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"
|
2019-05-03 00:12:36 +08:00
|
|
|
#include "clang/Lex/ExternalPreprocessorSource.h"
|
|
|
|
#include "clang/Lex/Preprocessor.h"
|
2018-09-14 20:36:06 +08:00
|
|
|
#include "clang/Lex/PreprocessorOptions.h"
|
2017-12-04 21:49:59 +08:00
|
|
|
#include "clang/Sema/CodeCompleteConsumer.h"
|
2019-04-10 23:16:54 +08:00
|
|
|
#include "clang/Sema/DeclSpec.h"
|
2017-12-04 21:49:59 +08:00
|
|
|
#include "clang/Sema/Sema.h"
|
2018-09-28 02:46:00 +08:00
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
2018-10-17 19:19:02 +08:00
|
|
|
#include "llvm/ADT/None.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"
|
2019-05-06 18:25:10 +08:00
|
|
|
#include "llvm/ADT/StringExtras.h"
|
[clangd] Improve global code completion when scope specifier is unresolved.
Summary:
Suppose `clangd::` is unresolved in the following example. Currently,
we simply use "clangd::" as the query scope. We can do better by combining with
accessible scopes in the context. The query scopes can be `{clangd::, clang::clangd::}`.
```
namespace clang { clangd::^ }
```
Reviewers: ilya-biryukov, sammccall, hokein, kadircet
Reviewed By: kadircet
Subscribers: MaskRay, jkorous, arphaman, kadircet, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58448
llvm-svn: 354963
2019-02-27 19:42:37 +08:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
2019-06-04 17:36:59 +08:00
|
|
|
#include "llvm/Support/Compiler.h"
|
2019-05-06 18:25:10 +08:00
|
|
|
#include "llvm/Support/Debug.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
|
|
|
|
[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;
|
|
|
|
case SK::Struct:
|
2020-02-14 21:55:51 +08:00
|
|
|
return CompletionItemKind::Struct;
|
2017-12-20 00:50:37 +08:00
|
|
|
case SK::Class:
|
|
|
|
case SK::Protocol:
|
|
|
|
case SK::Extension:
|
|
|
|
case SK::Union:
|
|
|
|
return CompletionItemKind::Class;
|
|
|
|
case SK::TypeAlias:
|
2019-05-29 23:10:19 +08:00
|
|
|
// We use the same kind as the VSCode C++ extension.
|
|
|
|
// FIXME: pick a better option when we have one.
|
|
|
|
return CompletionItemKind::Interface;
|
2017-12-20 00:50:37 +08:00
|
|
|
case SK::Using:
|
|
|
|
return CompletionItemKind::Reference;
|
|
|
|
case SK::Function:
|
|
|
|
case SK::ConversionFunction:
|
|
|
|
return CompletionItemKind::Function;
|
|
|
|
case SK::Variable:
|
|
|
|
case SK::Parameter:
|
2020-01-30 21:07:42 +08:00
|
|
|
case SK::NonTypeTemplateParm:
|
2017-12-20 00:50:37 +08:00
|
|
|
return CompletionItemKind::Variable;
|
|
|
|
case SK::Field:
|
|
|
|
return CompletionItemKind::Field;
|
|
|
|
case SK::EnumConstant:
|
2020-02-14 21:55:51 +08:00
|
|
|
return CompletionItemKind::EnumMember;
|
2017-12-20 00:50:37 +08:00
|
|
|
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;
|
2020-01-30 21:07:42 +08:00
|
|
|
case SK::TemplateTypeParm:
|
|
|
|
case SK::TemplateTemplateParm:
|
|
|
|
return CompletionItemKind::TypeParameter;
|
2017-12-20 00:50:37 +08:00
|
|
|
}
|
|
|
|
llvm_unreachable("Unhandled clang::index::SymbolKind.");
|
|
|
|
}
|
|
|
|
|
2018-06-09 05:17:19 +08:00
|
|
|
CompletionItemKind
|
|
|
|
toCompletionItemKind(CodeCompletionResult::ResultKind ResKind,
|
2018-09-18 17:08:28 +08:00
|
|
|
const NamedDecl *Decl,
|
|
|
|
CodeCompletionContext::Kind CtxKind) {
|
2018-06-09 05:17:19 +08:00
|
|
|
if (Decl)
|
|
|
|
return toCompletionItemKind(index::getSymbolInfo(Decl).Kind);
|
2018-09-18 17:08:28 +08:00
|
|
|
if (CtxKind == CodeCompletionContext::CCC_IncludedFile)
|
|
|
|
return CompletionItemKind::File;
|
2018-06-09 05:17:19 +08:00
|
|
|
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.");
|
|
|
|
}
|
|
|
|
|
2019-04-11 17:36:36 +08:00
|
|
|
// Identifier code completion result.
|
|
|
|
struct RawIdentifier {
|
|
|
|
llvm::StringRef Name;
|
|
|
|
unsigned References; // # of usages in file.
|
|
|
|
};
|
|
|
|
|
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 {
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::StringRef Name; // Used for filtering and sorting.
|
2018-01-19 22:34:02 +08:00
|
|
|
// We may have a result from Sema, from the index, or both.
|
|
|
|
const CodeCompletionResult *SemaResult = nullptr;
|
|
|
|
const Symbol *IndexResult = nullptr;
|
2019-04-11 17:36:36 +08:00
|
|
|
const RawIdentifier *IdentifierResult = nullptr;
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::SmallVector<llvm::StringRef, 1> RankedIncludeHeaders;
|
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
|
|
|
// Returns a token identifying the overload set this is part of.
|
|
|
|
// 0 indicates it's not part of any overload set.
|
2019-04-10 20:15:35 +08:00
|
|
|
size_t overloadSet(const CodeCompleteOptions &Opts) const {
|
2019-07-09 01:27:15 +08:00
|
|
|
if (!Opts.BundleOverloads.getValueOr(false))
|
2019-04-10 20:15:35 +08:00
|
|
|
return 0;
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::SmallString<256> Scratch;
|
[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 (IndexResult) {
|
|
|
|
switch (IndexResult->SymInfo.Kind) {
|
|
|
|
case index::SymbolKind::ClassMethod:
|
|
|
|
case index::SymbolKind::InstanceMethod:
|
|
|
|
case index::SymbolKind::StaticMethod:
|
2018-11-02 13:59:29 +08:00
|
|
|
#ifndef NDEBUG
|
|
|
|
llvm_unreachable("Don't expect members from index in code completion");
|
|
|
|
#else
|
2018-11-02 12:23:50 +08:00
|
|
|
LLVM_FALLTHROUGH;
|
2018-11-02 13:59:29 +08:00
|
|
|
#endif
|
[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
|
|
|
case index::SymbolKind::Function:
|
|
|
|
// We can't group overloads together that need different #includes.
|
|
|
|
// This could break #include insertion.
|
2019-01-07 23:45:19 +08:00
|
|
|
return llvm::hash_combine(
|
[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
|
|
|
(IndexResult->Scope + IndexResult->Name).toStringRef(Scratch),
|
2019-04-10 20:15:35 +08:00
|
|
|
headerToInsertIfAllowed(Opts).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;
|
|
|
|
}
|
|
|
|
}
|
2019-04-11 17:36:36 +08:00
|
|
|
if (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);
|
|
|
|
}
|
|
|
|
return llvm::hash_combine(Scratch,
|
|
|
|
headerToInsertIfAllowed(Opts).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
|
|
|
}
|
2019-04-11 17:36:36 +08:00
|
|
|
assert(IdentifierResult);
|
|
|
|
return 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
|
|
|
}
|
|
|
|
|
[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.
|
2019-04-10 20:15:35 +08:00
|
|
|
llvm::Optional<llvm::StringRef>
|
|
|
|
headerToInsertIfAllowed(const CodeCompleteOptions &Opts) const {
|
|
|
|
if (Opts.InsertIncludes == CodeCompleteOptions::NeverInsert ||
|
|
|
|
RankedIncludeHeaders.empty())
|
2018-10-20 23:30:37 +08:00
|
|
|
return None;
|
[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 (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())))
|
2018-10-20 23:30:37 +08:00
|
|
|
return None;
|
[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
|
|
|
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
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
using Bundle = llvm::SmallVector<CompletionCandidate, 4>;
|
[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 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 {
|
2019-04-11 17:36:36 +08:00
|
|
|
CodeCompletionBuilder(ASTContext *ASTCtx, const CompletionCandidate &C,
|
2018-06-29 22:47:57 +08:00
|
|
|
CodeCompletionString *SemaCCS,
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::ArrayRef<std::string> QueryScopes,
|
|
|
|
const IncludeInserter &Includes,
|
|
|
|
llvm::StringRef FileName,
|
2018-09-18 17:08:28 +08:00
|
|
|
CodeCompletionContext::Kind ContextKind,
|
2019-10-28 16:34:21 +08:00
|
|
|
const CodeCompleteOptions &Opts, bool GenerateSnippets)
|
2018-08-23 20:19:39 +08:00
|
|
|
: ASTCtx(ASTCtx), ExtractDocumentation(Opts.IncludeComments),
|
2019-10-28 16:34:21 +08:00
|
|
|
EnableFunctionArgSnippets(Opts.EnableFunctionArgSnippets),
|
|
|
|
GenerateSnippets(GenerateSnippets) {
|
2018-06-29 22:47:57 +08:00
|
|
|
add(C, SemaCCS);
|
|
|
|
if (C.SemaResult) {
|
2019-04-11 17:36:36 +08:00
|
|
|
assert(ASTCtx);
|
2018-07-06 19:50:49 +08:00
|
|
|
Completion.Origin |= SymbolOrigin::AST;
|
2020-01-29 03:23:46 +08:00
|
|
|
Completion.Name = std::string(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())
|
2018-10-20 23:30:37 +08:00
|
|
|
if (const auto *ND = dyn_cast<NamedDecl>(D))
|
2020-01-29 03:23:46 +08:00
|
|
|
Completion.Scope = std::string(
|
|
|
|
splitQualifiedName(printQualifiedName(*ND)).first);
|
2018-07-18 23:31:14 +08:00
|
|
|
}
|
2018-09-18 17:08:28 +08:00
|
|
|
Completion.Kind = toCompletionItemKind(
|
|
|
|
C.SemaResult->Kind, C.SemaResult->Declaration, ContextKind);
|
2018-09-27 22:21:07 +08:00
|
|
|
// Sema could provide more info on whether the completion was a file or
|
|
|
|
// folder.
|
|
|
|
if (Completion.Kind == CompletionItemKind::File &&
|
|
|
|
Completion.Name.back() == '/')
|
|
|
|
Completion.Kind = CompletionItemKind::Folder;
|
2018-08-08 16:59:29 +08:00
|
|
|
for (const auto &FixIt : C.SemaResult->FixIts) {
|
2019-04-11 17:36:36 +08:00
|
|
|
Completion.FixIts.push_back(toTextEdit(
|
|
|
|
FixIt, ASTCtx->getSourceManager(), ASTCtx->getLangOpts()));
|
2018-08-08 16:59:29 +08:00
|
|
|
}
|
2018-10-07 22:49:41 +08:00
|
|
|
llvm::sort(Completion.FixIts, [](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-09-07 02:52:26 +08:00
|
|
|
Completion.Deprecated |=
|
|
|
|
(C.SemaResult->Availability == CXAvailability_Deprecated);
|
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())
|
2020-01-29 03:23:46 +08:00
|
|
|
Completion.Scope = std::string(C.IndexResult->Scope);
|
2018-06-29 22:47:57 +08:00
|
|
|
if (Completion.Kind == CompletionItemKind::Missing)
|
|
|
|
Completion.Kind = toCompletionItemKind(C.IndexResult->SymInfo.Kind);
|
|
|
|
if (Completion.Name.empty())
|
2020-01-29 03:23:46 +08:00
|
|
|
Completion.Name = std::string(C.IndexResult->Name);
|
2018-09-28 02:46:00 +08:00
|
|
|
// If the completion was visible to Sema, no qualifier is needed. This
|
|
|
|
// avoids unneeded qualifiers in cases like with `using ns::X`.
|
|
|
|
if (Completion.RequiredQualifier.empty() && !C.SemaResult) {
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::StringRef ShortestQualifier = C.IndexResult->Scope;
|
|
|
|
for (llvm::StringRef Scope : QueryScopes) {
|
|
|
|
llvm::StringRef Qualifier = C.IndexResult->Scope;
|
2018-09-28 02:46:00 +08:00
|
|
|
if (Qualifier.consume_front(Scope) &&
|
|
|
|
Qualifier.size() < ShortestQualifier.size())
|
|
|
|
ShortestQualifier = Qualifier;
|
|
|
|
}
|
2020-01-29 03:23:46 +08:00
|
|
|
Completion.RequiredQualifier = std::string(ShortestQualifier);
|
2018-09-28 02:46:00 +08:00
|
|
|
}
|
2018-09-07 02:52:26 +08:00
|
|
|
Completion.Deprecated |= (C.IndexResult->Flags & Symbol::Deprecated);
|
2018-06-29 22:47:57 +08:00
|
|
|
}
|
2019-04-11 17:36:36 +08:00
|
|
|
if (C.IdentifierResult) {
|
|
|
|
Completion.Origin |= SymbolOrigin::Identifier;
|
|
|
|
Completion.Kind = CompletionItemKind::Text;
|
2020-01-29 03:23:46 +08:00
|
|
|
Completion.Name = std::string(C.IdentifierResult->Name);
|
2019-04-11 17:36:36 +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
|
|
|
|
|
|
|
// Turn absolute path into a literal string that can be #included.
|
2019-01-07 23:45:19 +08:00
|
|
|
auto Inserted = [&](llvm::StringRef Header)
|
|
|
|
-> llvm::Expected<std::pair<std::string, bool>> {
|
2019-09-23 22:39:37 +08:00
|
|
|
auto ResolvedDeclaring =
|
|
|
|
URI::resolve(C.IndexResult->CanonicalDeclaration.FileURI, FileName);
|
[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 (!ResolvedDeclaring)
|
|
|
|
return ResolvedDeclaring.takeError();
|
|
|
|
auto ResolvedInserted = toHeaderFile(Header, FileName);
|
|
|
|
if (!ResolvedInserted)
|
|
|
|
return ResolvedInserted.takeError();
|
2019-07-09 02:07:46 +08:00
|
|
|
auto Spelled = Includes.calculateIncludePath(*ResolvedInserted, FileName);
|
|
|
|
if (!Spelled)
|
|
|
|
return llvm::createStringError(llvm::inconvertibleErrorCode(),
|
|
|
|
"Header not on include path");
|
[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 std::make_pair(
|
2019-07-09 02:07:46 +08:00
|
|
|
std::move(*Spelled),
|
[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
|
|
|
Includes.shouldInsertInclude(*ResolvedDeclaring, *ResolvedInserted));
|
|
|
|
};
|
2019-04-10 20:15:35 +08:00
|
|
|
bool ShouldInsert = C.headerToInsertIfAllowed(Opts).hasValue();
|
[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
|
|
|
// 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 "
|
2019-07-10 17:18:09 +08:00
|
|
|
"(FileURI='{0}', IncludeHeader='{1}') into {2}: {3}",
|
|
|
|
C.IndexResult->CanonicalDeclaration.FileURI, Inc, FileName,
|
|
|
|
ToInclude.takeError());
|
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) {
|
2019-05-28 23:33:37 +08:00
|
|
|
bool IsPattern = C.SemaResult->Kind == CodeCompletionResult::RK_Pattern;
|
2018-06-29 22:47:57 +08:00
|
|
|
getSignature(*SemaCCS, &S.Signature, &S.SnippetSuffix,
|
2019-05-28 23:33:37 +08:00
|
|
|
&Completion.RequiredQualifier, IsPattern);
|
2018-06-29 22:47:57 +08:00
|
|
|
S.ReturnType = getReturnType(*SemaCCS);
|
|
|
|
} else if (C.IndexResult) {
|
2020-01-29 03:23:46 +08:00
|
|
|
S.Signature = std::string(C.IndexResult->Signature);
|
|
|
|
S.SnippetSuffix = std::string(C.IndexResult->CompletionSnippetSuffix);
|
|
|
|
S.ReturnType = std::string(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)
|
2020-01-29 03:23:46 +08:00
|
|
|
Completion.Documentation = std::string(C.IndexResult->Documentation);
|
2018-06-29 22:47:57 +08:00
|
|
|
else if (C.SemaResult)
|
2019-04-11 17:36:36 +08:00
|
|
|
Completion.Documentation = getDocComment(*ASTCtx, *C.SemaResult,
|
2018-06-29 22:47:57 +08:00
|
|
|
/*CommentsFromHeader=*/false);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
CodeCompletion build() {
|
|
|
|
Completion.ReturnType = summarizeReturnType();
|
|
|
|
Completion.Signature = summarizeSignature();
|
|
|
|
Completion.SnippetSuffix = summarizeSnippet();
|
|
|
|
Completion.BundleSize = Bundled.size();
|
|
|
|
return std::move(Completion);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
struct BundledEntry {
|
|
|
|
std::string SnippetSuffix;
|
|
|
|
std::string Signature;
|
|
|
|
std::string ReturnType;
|
|
|
|
};
|
|
|
|
|
2019-12-16 17:33:56 +08:00
|
|
|
// If all BundledEntries have the same value for a property, return it.
|
2018-06-29 22:47:57 +08:00
|
|
|
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 {
|
2019-10-28 16:34:21 +08:00
|
|
|
if (!GenerateSnippets)
|
|
|
|
return "";
|
2018-08-23 20:19:39 +08:00
|
|
|
auto *Snippet = onlyValue<&BundledEntry::SnippetSuffix>();
|
|
|
|
if (!Snippet)
|
|
|
|
// All bundles are function calls.
|
2018-09-26 13:45:31 +08:00
|
|
|
// FIXME(ibiryukov): sometimes add template arguments to a snippet, e.g.
|
|
|
|
// we need to complete 'forward<$1>($0)'.
|
2018-08-23 20:19:39 +08:00
|
|
|
return "($0)";
|
2018-09-26 13:45:31 +08:00
|
|
|
if (EnableFunctionArgSnippets)
|
|
|
|
return *Snippet;
|
|
|
|
|
|
|
|
// Replace argument snippets with a simplified pattern.
|
|
|
|
if (Snippet->empty())
|
|
|
|
return "";
|
|
|
|
if (Completion.Kind == CompletionItemKind::Function ||
|
|
|
|
Completion.Kind == CompletionItemKind::Method) {
|
|
|
|
// Functions snippets can be of 2 types:
|
|
|
|
// - containing only function arguments, e.g.
|
|
|
|
// foo(${1:int p1}, ${2:int p2});
|
|
|
|
// We transform this pattern to '($0)' or '()'.
|
|
|
|
// - template arguments and function arguments, e.g.
|
|
|
|
// foo<${1:class}>(${2:int p1}).
|
|
|
|
// We transform this pattern to '<$1>()$0' or '<$0>()'.
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
bool EmptyArgs = llvm::StringRef(*Snippet).endswith("()");
|
2018-09-26 13:45:31 +08:00
|
|
|
if (Snippet->front() == '<')
|
|
|
|
return EmptyArgs ? "<$1>()$0" : "<$1>($0)";
|
|
|
|
if (Snippet->front() == '(')
|
|
|
|
return EmptyArgs ? "()" : "($0)";
|
|
|
|
return *Snippet; // Not an arg snippet?
|
|
|
|
}
|
2019-05-29 23:10:19 +08:00
|
|
|
// 'CompletionItemKind::Interface' matches template type aliases.
|
|
|
|
if (Completion.Kind == CompletionItemKind::Interface ||
|
2018-09-26 13:45:31 +08:00
|
|
|
Completion.Kind == CompletionItemKind::Class) {
|
|
|
|
if (Snippet->front() != '<')
|
|
|
|
return *Snippet; // Not an arg snippet?
|
|
|
|
|
|
|
|
// Classes and template using aliases can only have template arguments,
|
|
|
|
// e.g. Foo<${1:class}>.
|
2019-01-07 23:45:19 +08:00
|
|
|
if (llvm::StringRef(*Snippet).endswith("<>"))
|
2018-09-26 13:45:31 +08:00
|
|
|
return "<>"; // can happen with defaulted template arguments.
|
|
|
|
return "<$0>";
|
|
|
|
}
|
2018-08-23 20:19:39 +08:00
|
|
|
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 "(…)";
|
|
|
|
}
|
|
|
|
|
2019-04-11 17:36:36 +08:00
|
|
|
// ASTCtx can be nullptr if not run with sema.
|
|
|
|
ASTContext *ASTCtx;
|
2018-06-29 22:47:57 +08:00
|
|
|
CodeCompletion Completion;
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::SmallVector<BundledEntry, 1> Bundled;
|
2018-06-29 22:47:57 +08:00
|
|
|
bool ExtractDocumentation;
|
2018-08-23 20:19:39 +08:00
|
|
|
bool EnableFunctionArgSnippets;
|
2019-10-28 16:34:21 +08:00
|
|
|
/// When false, no snippets are generated argument lists.
|
|
|
|
bool GenerateSnippets;
|
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.
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::Optional<SymbolID> getSymbolID(const CodeCompletionResult &R,
|
|
|
|
const SourceManager &SM) {
|
2018-01-19 22:34:02 +08:00
|
|
|
switch (R.Kind) {
|
|
|
|
case CodeCompletionResult::RK_Declaration:
|
|
|
|
case CodeCompletionResult::RK_Pattern: {
|
2020-02-04 21:42:06 +08:00
|
|
|
// Computing USR caches linkage, which may change after code completion.
|
|
|
|
if (hasUnstableLinkage(R.Declaration))
|
|
|
|
return llvm::None;
|
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:
|
2019-11-11 19:38:17 +08:00
|
|
|
return clang::clangd::getSymbolID(R.Macro->getName(), R.MacroDefInfo, SM);
|
2018-01-19 22:34:02 +08:00
|
|
|
case CodeCompletionResult::RK_Keyword:
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
llvm_unreachable("unknown CodeCompletionResult kind");
|
|
|
|
}
|
|
|
|
|
2019-12-16 17:33:56 +08:00
|
|
|
// Scopes of the partial identifier we're trying to complete.
|
2018-01-23 19:37:26 +08:00
|
|
|
// 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.
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::Optional<std::string> UnresolvedQualifier;
|
2018-01-23 19:37:26 +08:00
|
|
|
|
2018-11-06 19:17:40 +08:00
|
|
|
// Construct scopes being queried in indexes. The results are deduplicated.
|
2018-01-23 19:37:26 +08:00
|
|
|
// This method format the scopes to match the index request representation.
|
|
|
|
std::vector<std::string> scopesForIndexQuery() {
|
2018-11-06 19:17:40 +08:00
|
|
|
std::set<std::string> Results;
|
2019-01-07 23:45:19 +08:00
|
|
|
for (llvm::StringRef AS : AccessibleScopes)
|
2018-11-06 19:17:40 +08:00
|
|
|
Results.insert(
|
[clangd] Improve global code completion when scope specifier is unresolved.
Summary:
Suppose `clangd::` is unresolved in the following example. Currently,
we simply use "clangd::" as the query scope. We can do better by combining with
accessible scopes in the context. The query scopes can be `{clangd::, clang::clangd::}`.
```
namespace clang { clangd::^ }
```
Reviewers: ilya-biryukov, sammccall, hokein, kadircet
Reviewed By: kadircet
Subscribers: MaskRay, jkorous, arphaman, kadircet, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58448
llvm-svn: 354963
2019-02-27 19:42:37 +08:00
|
|
|
(AS + (UnresolvedQualifier ? *UnresolvedQualifier : "")).str());
|
2018-11-06 19:17:40 +08:00
|
|
|
return {Results.begin(), Results.end()};
|
2018-01-19 22:34:02 +08:00
|
|
|
}
|
2017-12-20 00:50:37 +08:00
|
|
|
};
|
|
|
|
|
2018-09-28 02:46:00 +08:00
|
|
|
// Get all scopes that will be queried in indexes and whether symbols from
|
2018-10-17 19:19:02 +08:00
|
|
|
// any scope is allowed. The first scope in the list is the preferred scope
|
|
|
|
// (e.g. enclosing namespace).
|
2018-09-28 02:46:00 +08:00
|
|
|
std::pair<std::vector<std::string>, bool>
|
2018-10-17 19:19:02 +08:00
|
|
|
getQueryScopes(CodeCompletionContext &CCContext, const Sema &CCSema,
|
2019-04-10 23:16:54 +08:00
|
|
|
const CompletionPrefix &HeuristicPrefix,
|
2018-09-28 02:46:00 +08:00
|
|
|
const CodeCompleteOptions &Opts) {
|
2019-04-10 23:16:54 +08:00
|
|
|
SpecifiedScope Scopes;
|
|
|
|
for (auto *Context : CCContext.getVisitedContexts()) {
|
|
|
|
if (isa<TranslationUnitDecl>(Context))
|
|
|
|
Scopes.AccessibleScopes.push_back(""); // global namespace
|
|
|
|
else if (isa<NamespaceDecl>(Context))
|
|
|
|
Scopes.AccessibleScopes.push_back(printNamespaceScope(*Context));
|
|
|
|
}
|
2018-01-23 19:37:26 +08:00
|
|
|
|
2019-04-10 23:16:54 +08:00
|
|
|
const CXXScopeSpec *SemaSpecifier =
|
|
|
|
CCContext.getCXXScopeSpecifier().getValueOr(nullptr);
|
|
|
|
// Case 1: unqualified completion.
|
|
|
|
if (!SemaSpecifier) {
|
|
|
|
// Case 2 (exception): sema saw no qualifier, but there appears to be one!
|
|
|
|
// This can happen e.g. in incomplete macro expansions. Use heuristics.
|
|
|
|
if (!HeuristicPrefix.Qualifier.empty()) {
|
|
|
|
vlog("Sema said no scope specifier, but we saw {0} in the source code",
|
|
|
|
HeuristicPrefix.Qualifier);
|
|
|
|
StringRef SpelledSpecifier = HeuristicPrefix.Qualifier;
|
|
|
|
if (SpelledSpecifier.consume_front("::"))
|
|
|
|
Scopes.AccessibleScopes = {""};
|
2020-01-29 03:23:46 +08:00
|
|
|
Scopes.UnresolvedQualifier = std::string(SpelledSpecifier);
|
2019-04-10 23:16:54 +08:00
|
|
|
return {Scopes.scopesForIndexQuery(), false};
|
|
|
|
}
|
|
|
|
// The enclosing namespace must be first, it gets a quality boost.
|
|
|
|
std::vector<std::string> EnclosingAtFront;
|
2018-10-17 19:19:02 +08:00
|
|
|
std::string EnclosingScope = printNamespaceScope(*CCSema.CurContext);
|
2019-04-10 23:16:54 +08:00
|
|
|
EnclosingAtFront.push_back(EnclosingScope);
|
|
|
|
for (auto &S : Scopes.scopesForIndexQuery()) {
|
2018-10-17 19:19:02 +08:00
|
|
|
if (EnclosingScope != S)
|
2019-04-10 23:16:54 +08:00
|
|
|
EnclosingAtFront.push_back(std::move(S));
|
2018-10-17 19:19:02 +08:00
|
|
|
}
|
2019-04-10 23:16:54 +08:00
|
|
|
// Allow AllScopes completion as there is no explicit scope qualifier.
|
|
|
|
return {EnclosingAtFront, Opts.AllScopes};
|
2018-01-23 19:37:26 +08:00
|
|
|
}
|
2019-04-10 23:16:54 +08:00
|
|
|
// Case 3: sema saw and resolved a scope qualifier.
|
2019-04-10 23:45:05 +08:00
|
|
|
if (SemaSpecifier && SemaSpecifier->isValid())
|
2019-04-10 23:16:54 +08:00
|
|
|
return {Scopes.scopesForIndexQuery(), false};
|
|
|
|
|
|
|
|
// Case 4: There was a qualifier, and Sema didn't resolve it.
|
|
|
|
Scopes.AccessibleScopes.push_back(""); // Make sure global scope is included.
|
|
|
|
llvm::StringRef SpelledSpecifier = Lexer::getSourceText(
|
|
|
|
CharSourceRange::getCharRange(SemaSpecifier->getRange()),
|
|
|
|
CCSema.SourceMgr, clang::LangOptions());
|
[clangd] Improve global code completion when scope specifier is unresolved.
Summary:
Suppose `clangd::` is unresolved in the following example. Currently,
we simply use "clangd::" as the query scope. We can do better by combining with
accessible scopes in the context. The query scopes can be `{clangd::, clang::clangd::}`.
```
namespace clang { clangd::^ }
```
Reviewers: ilya-biryukov, sammccall, hokein, kadircet
Reviewed By: kadircet
Subscribers: MaskRay, jkorous, arphaman, kadircet, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58448
llvm-svn: 354963
2019-02-27 19:42:37 +08:00
|
|
|
if (SpelledSpecifier.consume_front("::"))
|
2019-04-10 23:16:54 +08:00
|
|
|
Scopes.AccessibleScopes = {""};
|
2020-01-29 03:23:46 +08:00
|
|
|
Scopes.UnresolvedQualifier = std::string(SpelledSpecifier);
|
2018-01-23 19:37:26 +08:00
|
|
|
// Sema excludes the trailing "::".
|
2019-04-10 23:16:54 +08:00
|
|
|
if (!Scopes.UnresolvedQualifier->empty())
|
|
|
|
*Scopes.UnresolvedQualifier += "::";
|
2018-01-23 19:37:26 +08:00
|
|
|
|
2019-04-10 23:16:54 +08:00
|
|
|
return {Scopes.scopesForIndexQuery(), false};
|
2018-01-23 19:37:26 +08:00
|
|
|
}
|
|
|
|
|
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_ParenthesizedExpression:
|
|
|
|
case CodeCompletionContext::CCC_ObjCInterfaceName:
|
|
|
|
case CodeCompletionContext::CCC_ObjCCategoryName:
|
2018-10-24 23:24:29 +08:00
|
|
|
case CodeCompletionContext::CCC_Symbol:
|
|
|
|
case CodeCompletionContext::CCC_SymbolOrNewName:
|
2018-05-24 19:20:19 +08:00
|
|
|
return true;
|
|
|
|
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_SelectorName:
|
|
|
|
case CodeCompletionContext::CCC_TypeQualifiers:
|
|
|
|
case CodeCompletionContext::CCC_ObjCInstanceMessage:
|
|
|
|
case CodeCompletionContext::CCC_ObjCClassMessage:
|
2018-09-18 17:08:28 +08:00
|
|
|
case CodeCompletionContext::CCC_IncludedFile:
|
2018-10-24 23:24:29 +08:00
|
|
|
// FIXME: Provide identifier based completions for the following contexts:
|
|
|
|
case CodeCompletionContext::CCC_Other: // Be conservative.
|
|
|
|
case CodeCompletionContext::CCC_NaturalLanguage:
|
2018-05-24 19:20:19 +08:00
|
|
|
case CodeCompletionContext::CCC_Recovery:
|
2018-10-24 23:24:29 +08:00
|
|
|
case CodeCompletionContext::CCC_NewName:
|
2018-05-24 19:20:19 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
llvm_unreachable("unknown code completion context");
|
|
|
|
}
|
|
|
|
|
2018-11-30 19:12:40 +08:00
|
|
|
static bool isInjectedClass(const NamedDecl &D) {
|
|
|
|
if (auto *R = dyn_cast_or_null<RecordDecl>(&D))
|
|
|
|
if (R->isInjectedClassName())
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
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()?
|
2018-11-30 19:12:40 +08:00
|
|
|
if (isInjectedClass(D))
|
|
|
|
return true;
|
2018-06-07 20:49:17 +08:00
|
|
|
// 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,
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::unique_function<void()> ResultsCallback)
|
2019-04-19 01:35:55 +08:00
|
|
|
: CodeCompleteConsumer(Opts.getClangCompleteOpts()),
|
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];
|
2018-10-24 21:51:44 +08:00
|
|
|
// Class members that are shadowed by subclasses are usually noise.
|
|
|
|
if (Result.Hidden && Result.Declaration &&
|
|
|
|
Result.Declaration->isCXXClassMember())
|
2018-01-10 21:51:09 +08:00
|
|
|
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-11-30 19:12:40 +08:00
|
|
|
// Skip injected class name when no class scope is not explicitly set.
|
|
|
|
// E.g. show injected A::A in `using A::A^` but not in "A^".
|
|
|
|
if (Result.Declaration && !Context.getCXXScopeSpecifier().hasValue() &&
|
|
|
|
isInjectedClass(*Result.Declaration))
|
|
|
|
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).
|
2019-01-07 23:45:19 +08:00
|
|
|
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;
|
2019-01-07 23:45:19 +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.
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::Optional<SymbolID> IDForDoc;
|
2018-08-17 17:32:30 +08:00
|
|
|
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-09-04 00:37:59 +08:00
|
|
|
const SymbolIndex *Index, SignatureHelp &SigHelp)
|
2019-06-04 17:36:59 +08:00
|
|
|
: CodeCompleteConsumer(CodeCompleteOpts), SigHelp(SigHelp),
|
2017-12-04 21:49:59 +08:00
|
|
|
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.
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::DenseMap<SymbolID, std::string> FetchedDocs;
|
2018-08-17 17:32:30 +08:00
|
|
|
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())
|
2020-01-29 03:23:46 +08:00
|
|
|
FetchedDocs[S.ID] = std::string(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());
|
|
|
|
}
|
|
|
|
|
2019-01-03 21:28:05 +08:00
|
|
|
llvm::sort(ScoredSignatures, [](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.
|
2019-12-16 17:33:56 +08:00
|
|
|
// - Alphabetically smaller is better.
|
2019-01-03 21:28:05 +08:00
|
|
|
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;
|
|
|
|
});
|
2018-08-17 17:32:30 +08:00
|
|
|
|
|
|
|
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:
|
2019-06-04 17:36:59 +08:00
|
|
|
void processParameterChunk(llvm::StringRef ChunkText,
|
2019-06-06 16:32:25 +08:00
|
|
|
SignatureInformation &Signature) const {
|
2019-06-04 17:36:59 +08:00
|
|
|
// (!) this is O(n), should still be fast compared to building ASTs.
|
|
|
|
unsigned ParamStartOffset = lspLength(Signature.label);
|
|
|
|
unsigned ParamEndOffset = ParamStartOffset + lspLength(ChunkText);
|
|
|
|
// A piece of text that describes the parameter that corresponds to
|
|
|
|
// the code-completion location within a function call, message send,
|
|
|
|
// macro invocation, etc.
|
|
|
|
Signature.label += ChunkText;
|
|
|
|
ParameterInformation Info;
|
|
|
|
Info.labelOffsets.emplace(ParamStartOffset, ParamEndOffset);
|
|
|
|
// FIXME: only set 'labelOffsets' when all clients migrate out of it.
|
2020-01-29 03:23:46 +08:00
|
|
|
Info.labelString = std::string(ChunkText);
|
2019-06-04 17:36:59 +08:00
|
|
|
|
|
|
|
Signature.parameters.push_back(std::move(Info));
|
|
|
|
}
|
|
|
|
|
|
|
|
void processOptionalChunk(const CodeCompletionString &CCS,
|
|
|
|
SignatureInformation &Signature,
|
|
|
|
SignatureQualitySignals &Signal) const {
|
|
|
|
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.");
|
|
|
|
processOptionalChunk(*Chunk.Optional, Signature, Signal);
|
|
|
|
break;
|
|
|
|
case CodeCompletionString::CK_VerticalSpace:
|
|
|
|
break;
|
|
|
|
case CodeCompletionString::CK_CurrentParameter:
|
|
|
|
case CodeCompletionString::CK_Placeholder:
|
2019-06-06 16:32:25 +08:00
|
|
|
processParameterChunk(Chunk.Text, Signature);
|
2019-06-04 17:36:59 +08:00
|
|
|
Signal.NumberOfOptionalParameters++;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
Signature.label += Chunk.Text;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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,
|
2019-01-07 23:45:19 +08:00
|
|
|
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;
|
2019-06-04 17:36:59 +08:00
|
|
|
case CodeCompletionString::CK_CurrentParameter:
|
2017-12-04 21:49:59 +08:00
|
|
|
case CodeCompletionString::CK_Placeholder:
|
2019-06-06 16:32:25 +08:00
|
|
|
processParameterChunk(Chunk.Text, Signature);
|
2018-08-13 16:40:05 +08:00
|
|
|
Signal.NumberOfParameters++;
|
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.");
|
2019-06-04 17:36:59 +08:00
|
|
|
processOptionalChunk(*Chunk.Optional, Signature, 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;
|
2020-02-04 21:42:06 +08:00
|
|
|
const FunctionDecl *Func = Candidate.getFunction();
|
|
|
|
if (Func && Result.Signature.documentation.empty()) {
|
|
|
|
// Computing USR caches linkage, which may change after code completion.
|
|
|
|
if (!hasUnstableLinkage(Func))
|
|
|
|
Result.IDForDoc = clangd::getSymbolID(Func);
|
|
|
|
}
|
2018-08-17 17:32:30 +08:00
|
|
|
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;
|
2018-10-02 18:43:55 +08:00
|
|
|
const PreambleData *Preamble;
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::StringRef Contents;
|
2019-04-10 23:16:54 +08:00
|
|
|
size_t Offset;
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem> VFS;
|
2018-01-19 22:34:02 +08:00
|
|
|
};
|
|
|
|
|
2019-05-03 00:12:36 +08:00
|
|
|
void loadMainFilePreambleMacros(const Preprocessor &PP,
|
|
|
|
const PreambleData &Preamble) {
|
|
|
|
// The ExternalPreprocessorSource has our macros, if we know where to look.
|
|
|
|
// We can read all the macros using PreambleMacros->ReadDefinedMacros(),
|
|
|
|
// but this includes transitively included files, so may deserialize a lot.
|
|
|
|
ExternalPreprocessorSource *PreambleMacros = PP.getExternalSource();
|
|
|
|
// As we have the names of the macros, we can look up their IdentifierInfo
|
|
|
|
// and then use this to load just the macros we want.
|
|
|
|
IdentifierInfoLookup *PreambleIdentifiers =
|
|
|
|
PP.getIdentifierTable().getExternalIdentifierLookup();
|
|
|
|
if (!PreambleIdentifiers || !PreambleMacros)
|
|
|
|
return;
|
2019-09-24 19:14:06 +08:00
|
|
|
for (const auto &MacroName : Preamble.Macros.Names)
|
|
|
|
if (auto *II = PreambleIdentifiers->get(MacroName.getKey()))
|
2019-05-03 00:12:36 +08:00
|
|
|
if (II->isOutOfDate())
|
|
|
|
PreambleMacros->updateOutOfDateIdentifier(*II);
|
|
|
|
}
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// 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");
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem> VFS = Input.VFS;
|
2018-10-02 18:43:55 +08:00
|
|
|
if (Input.Preamble && Input.Preamble->StatCache)
|
|
|
|
VFS = Input.Preamble->StatCache->getConsumingFS(std::move(VFS));
|
2019-01-28 22:01:55 +08:00
|
|
|
ParseInputs ParseInput;
|
|
|
|
ParseInput.CompileCommand = Input.Command;
|
|
|
|
ParseInput.FS = VFS;
|
2020-01-29 03:23:46 +08:00
|
|
|
ParseInput.Contents = std::string(Input.Contents);
|
2019-01-28 22:01:55 +08:00
|
|
|
ParseInput.Opts = ParseOptions();
|
[clangd] Surface errors from command-line parsing
Summary:
Those errors are exposed at the first character of a file,
for a lack of a better place.
Previously, all errors were stored inside the AST and report
accordingly. However, errors in command-line argument parsing could
result in failure to produce the AST, so we need an alternative ways to
report those errors.
We take the following approach in this patch:
- buildCompilerInvocation() now requires an explicit DiagnosticConsumer.
- TUScheduler and TestTU now collect the diagnostics produced when
parsing command line arguments.
If pasing of the AST failed, diagnostics are reported via a new
ParsingCallbacks::onFailedAST method.
If parsing of the AST succeeded, any errors produced during
command-line parsing are stored alongside the AST inside the
ParsedAST instance and reported as previously by calling the
ParsingCallbacks::onMainAST method;
- The client code that uses ClangdServer's DiagnosticConsumer
does not need to change, it will receive new diagnostics in the
onDiagnosticsReady() callback
Errors produced when parsing command-line arguments are collected using
the same StoreDiags class that is used to collect all other errors. They
are recognized by their location being invalid. IIUC, the location is
invalid as there is no source manager at this point, it is created at a
later stage.
Although technically we might also get diagnostics that mention the
command-line arguments FileID with after the source manager was created
(and they have valid source locations), we choose to not handle those
and they are dropped as not coming from the main file. AFAICT, those
diagnostics should always be notes, therefore it's safe to drop them
without loosing too much information.
Reviewers: kadircet
Reviewed By: kadircet
Subscribers: nridge, javed.absar, MaskRay, jkorous, arphaman, cfe-commits, gribozavr
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66759
llvm-svn: 370177
2019-08-28 17:24:55 +08:00
|
|
|
|
|
|
|
IgnoreDiagnostics IgnoreDiags;
|
|
|
|
auto CI = buildCompilerInvocation(ParseInput, IgnoreDiags);
|
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.SkipFunctionBodies = 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;
|
2020-01-29 03:23:46 +08:00
|
|
|
FrontendOpts.CodeCompletionAt.FileName = std::string(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
|
|
|
std::tie(FrontendOpts.CodeCompletionAt.Line,
|
|
|
|
FrontendOpts.CodeCompletionAt.Column) =
|
2019-04-10 23:16:54 +08:00
|
|
|
offsetToClangLineColumn(Input.Contents, Input.Offset);
|
2017-12-04 21:49:59 +08:00
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
std::unique_ptr<llvm::MemoryBuffer> ContentsBuffer =
|
|
|
|
llvm::MemoryBuffer::getMemBufferCopy(Input.Contents, Input.FileName);
|
2018-05-28 20:11:37 +08:00
|
|
|
// 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.
|
2018-09-14 20:36:06 +08:00
|
|
|
// However, if we're completing *inside* the preamble section of the draft,
|
|
|
|
// overriding the preamble will break sema completion. Fortunately we can just
|
|
|
|
// skip all includes in this case; these completions are really simple.
|
2019-05-03 00:12:36 +08:00
|
|
|
PreambleBounds PreambleRegion =
|
|
|
|
ComputePreambleBounds(*CI->getLangOpts(), ContentsBuffer.get(), 0);
|
|
|
|
bool CompletingInPreamble = PreambleRegion.Size > Input.Offset;
|
2018-05-28 20:11:37 +08:00
|
|
|
// NOTE: we must call BeginSourceFile after prepareCompilerInstance. Otherwise
|
|
|
|
// the remapped buffers do not get freed.
|
|
|
|
auto Clang = prepareCompilerInstance(
|
2018-10-02 18:43:55 +08:00
|
|
|
std::move(CI),
|
|
|
|
(Input.Preamble && !CompletingInPreamble) ? &Input.Preamble->Preamble
|
|
|
|
: nullptr,
|
[clangd] Surface errors from command-line parsing
Summary:
Those errors are exposed at the first character of a file,
for a lack of a better place.
Previously, all errors were stored inside the AST and report
accordingly. However, errors in command-line argument parsing could
result in failure to produce the AST, so we need an alternative ways to
report those errors.
We take the following approach in this patch:
- buildCompilerInvocation() now requires an explicit DiagnosticConsumer.
- TUScheduler and TestTU now collect the diagnostics produced when
parsing command line arguments.
If pasing of the AST failed, diagnostics are reported via a new
ParsingCallbacks::onFailedAST method.
If parsing of the AST succeeded, any errors produced during
command-line parsing are stored alongside the AST inside the
ParsedAST instance and reported as previously by calling the
ParsingCallbacks::onMainAST method;
- The client code that uses ClangdServer's DiagnosticConsumer
does not need to change, it will receive new diagnostics in the
onDiagnosticsReady() callback
Errors produced when parsing command-line arguments are collected using
the same StoreDiags class that is used to collect all other errors. They
are recognized by their location being invalid. IIUC, the location is
invalid as there is no source manager at this point, it is created at a
later stage.
Although technically we might also get diagnostics that mention the
command-line arguments FileID with after the source manager was created
(and they have valid source locations), we choose to not handle those
and they are dropped as not coming from the main file. AFAICT, those
diagnostics should always be notes, therefore it's safe to drop them
without loosing too much information.
Reviewers: kadircet
Reviewed By: kadircet
Subscribers: nridge, javed.absar, MaskRay, jkorous, arphaman, cfe-commits, gribozavr
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66759
llvm-svn: 370177
2019-08-28 17:24:55 +08:00
|
|
|
std::move(ContentsBuffer), std::move(VFS), IgnoreDiags);
|
2018-09-14 20:36:06 +08:00
|
|
|
Clang->getPreprocessorOpts().SingleFileParseMode = CompletingInPreamble;
|
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;
|
|
|
|
}
|
2019-05-03 00:12:36 +08:00
|
|
|
// Macros can be defined within the preamble region of the main file.
|
|
|
|
// They don't fall nicely into our index/Sema dichotomy:
|
|
|
|
// - they're not indexed for completion (they're not available across files)
|
|
|
|
// - but Sema code complete won't see them: as part of the preamble, they're
|
|
|
|
// deserialized only when mentioned.
|
|
|
|
// Force them to be deserialized so SemaCodeComplete sees them.
|
|
|
|
if (Input.Preamble)
|
|
|
|
loadMainFilePreambleMacros(Clang->getPreprocessor(), *Input.Preamble);
|
2018-07-03 16:09:29 +08:00
|
|
|
if (Includes)
|
|
|
|
Clang->getPreprocessor().addPPCallbacks(
|
|
|
|
collectIncludeStructureCallback(Clang->getSourceManager(), Includes));
|
2019-06-27 03:50:12 +08:00
|
|
|
if (llvm::Error Err = Action.Execute()) {
|
|
|
|
log("Execute() failed when running codeComplete for {0}: {1}",
|
|
|
|
Input.FileName, toString(std::move(Err)));
|
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.
|
2019-04-10 23:16:54 +08:00
|
|
|
FuzzyFindRequest speculativeFuzzyFindRequestForCompletion(
|
|
|
|
FuzzyFindRequest CachedReq, const CompletionPrefix &HeuristicPrefix) {
|
2020-01-29 03:23:46 +08:00
|
|
|
CachedReq.Query = std::string(HeuristicPrefix.Name);
|
[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
|
|
|
return CachedReq;
|
|
|
|
}
|
|
|
|
|
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;
|
2019-01-03 21:28:05 +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;
|
2019-04-11 17:36:36 +08:00
|
|
|
CodeCompletionContext::Kind CCContextKind = CodeCompletionContext::CCC_Other;
|
2019-10-28 16:34:21 +08:00
|
|
|
bool IsUsingDeclaration = false;
|
2019-04-11 17:36:36 +08:00
|
|
|
// Counters for logging.
|
|
|
|
int NSema = 0, NIndex = 0, NSemaAndIndex = 0, NIdent = 0;
|
|
|
|
bool Incomplete = false; // Would more be available with a higher limit?
|
2019-04-10 23:16:54 +08:00
|
|
|
CompletionPrefix HeuristicPrefix;
|
2019-06-04 17:36:59 +08:00
|
|
|
llvm::Optional<FuzzyMatcher> Filter; // Initialized once Sema runs.
|
2019-04-11 17:36:36 +08:00
|
|
|
Range ReplacedRange;
|
2018-09-28 02:46:00 +08:00
|
|
|
std::vector<std::string> QueryScopes; // Initialized once Sema runs.
|
2018-10-17 19:19:02 +08:00
|
|
|
// Initialized once QueryScopes is initialized, if there are scopes.
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::Optional<ScopeDistance> ScopeProximity;
|
2018-11-26 23:38:01 +08:00
|
|
|
llvm::Optional<OpaqueType> PreferredType; // Initialized once Sema runs.
|
2018-09-28 02:46:00 +08:00
|
|
|
// Whether to query symbols from any scope. Initialized once Sema runs.
|
|
|
|
bool AllScopes = false;
|
2019-05-06 18:25:10 +08:00
|
|
|
llvm::StringSet<> ContextWords;
|
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.
|
2019-01-07 23:45:19 +08:00
|
|
|
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.
|
2019-01-07 23:45:19 +08:00
|
|
|
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");
|
2019-04-10 23:16:54 +08:00
|
|
|
HeuristicPrefix =
|
|
|
|
guessCompletionPrefix(SemaCCInput.Contents, SemaCCInput.Offset);
|
2019-05-06 18:25:10 +08:00
|
|
|
populateContextWords(SemaCCInput.Contents);
|
[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());
|
2019-04-10 23:16:54 +08:00
|
|
|
SpecReq = speculativeFuzzyFindRequestForCompletion(
|
|
|
|
*SpecFuzzyFind->CachedReq, HeuristicPrefix);
|
|
|
|
SpecFuzzyFind->Result = startAsyncFuzzyFind(*Opts.Index, *SpecReq);
|
[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-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;
|
2019-08-15 07:52:23 +08:00
|
|
|
auto RecorderOwner = std::make_unique<CompletionRecorder>(Opts, [&]() {
|
[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
|
|
|
assert(Recorder && "Recorder is not set");
|
2019-04-11 17:36:36 +08:00
|
|
|
CCContextKind = Recorder->CCContext.getKind();
|
2019-10-28 16:34:21 +08:00
|
|
|
IsUsingDeclaration = Recorder->CCContext.isUsingDeclaration();
|
2019-01-28 22:01:55 +08:00
|
|
|
auto Style = getFormatStyleForFile(
|
|
|
|
SemaCCInput.FileName, SemaCCInput.Contents, SemaCCInput.VFS.get());
|
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(
|
2019-01-28 22:01:55 +08:00
|
|
|
SemaCCInput.FileName, SemaCCInput.Contents, Style,
|
2018-07-03 16:09:29 +08:00
|
|
|
SemaCCInput.Command.Directory,
|
2019-04-11 17:36:36 +08:00
|
|
|
&Recorder->CCSema->getPreprocessor().getHeaderSearchInfo());
|
2018-07-03 16:09:29 +08:00
|
|
|
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();
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::StringMap<SourceParams> ProxSources;
|
2018-07-03 16:09:29 +08:00
|
|
|
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",
|
2019-04-11 17:36:36 +08:00
|
|
|
getCompletionKindString(CCContextKind));
|
2018-11-26 23:38:01 +08:00
|
|
|
log("Code complete: sema context {0}, query scopes [{1}] (AnyScope={2}), "
|
2019-10-28 16:34:21 +08:00
|
|
|
"expected type {3}{4}",
|
2019-04-11 17:36:36 +08:00
|
|
|
getCompletionKindString(CCContextKind),
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::join(QueryScopes.begin(), QueryScopes.end(), ","), AllScopes,
|
2018-11-26 23:38:01 +08:00
|
|
|
PreferredType ? Recorder->CCContext.getPreferredType().getAsString()
|
2019-10-28 16:34:21 +08:00
|
|
|
: "<none>",
|
|
|
|
IsUsingDeclaration ? ", inside using declaration" : "");
|
[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);
|
2019-04-26 15:45:49 +08:00
|
|
|
logResults(Output, Tracer);
|
|
|
|
return Output;
|
|
|
|
}
|
2018-01-19 22:34:02 +08:00
|
|
|
|
2019-04-26 15:45:49 +08:00
|
|
|
void logResults(const CodeCompleteResult &Output, const trace::Span &Tracer) {
|
2018-01-31 01:20:54 +08:00
|
|
|
SPAN_ATTACH(Tracer, "sema_results", NSema);
|
|
|
|
SPAN_ATTACH(Tracer, "index_results", NIndex);
|
2019-04-11 17:36:36 +08:00
|
|
|
SPAN_ATTACH(Tracer, "merged_results", NSemaAndIndex);
|
|
|
|
SPAN_ATTACH(Tracer, "identifier_results", NIdent);
|
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, "
|
2019-04-11 17:36:36 +08:00
|
|
|
"{2} matched, {3} from identifiers, {4} returned{5}.",
|
|
|
|
NSema, NIndex, NSemaAndIndex, NIdent, Output.Completions.size(),
|
[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
|
|
|
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.
|
|
|
|
}
|
|
|
|
|
2019-04-11 17:36:36 +08:00
|
|
|
CodeCompleteResult
|
|
|
|
runWithoutSema(llvm::StringRef Content, size_t Offset,
|
|
|
|
llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem> VFS) && {
|
2019-04-26 15:45:49 +08:00
|
|
|
trace::Span Tracer("CodeCompleteWithoutSema");
|
2019-04-11 17:36:36 +08:00
|
|
|
// Fill in fields normally set by runWithSema()
|
2019-04-26 15:45:49 +08:00
|
|
|
HeuristicPrefix = guessCompletionPrefix(Content, Offset);
|
2019-05-06 18:25:10 +08:00
|
|
|
populateContextWords(Content);
|
2019-04-11 17:36:36 +08:00
|
|
|
CCContextKind = CodeCompletionContext::CCC_Recovery;
|
2019-10-28 16:34:21 +08:00
|
|
|
IsUsingDeclaration = false;
|
2019-04-26 15:45:49 +08:00
|
|
|
Filter = FuzzyMatcher(HeuristicPrefix.Name);
|
2019-04-11 17:36:36 +08:00
|
|
|
auto Pos = offsetToPosition(Content, Offset);
|
|
|
|
ReplacedRange.start = ReplacedRange.end = Pos;
|
2019-04-26 15:45:49 +08:00
|
|
|
ReplacedRange.start.character -= HeuristicPrefix.Name.size();
|
2019-04-11 17:36:36 +08:00
|
|
|
|
|
|
|
llvm::StringMap<SourceParams> ProxSources;
|
|
|
|
ProxSources[FileName].Cost = 0;
|
|
|
|
FileProximity.emplace(ProxSources);
|
|
|
|
|
|
|
|
auto Style = getFormatStyleForFile(FileName, Content, VFS.get());
|
|
|
|
// This will only insert verbatim headers.
|
|
|
|
Inserter.emplace(FileName, Content, Style,
|
|
|
|
/*BuildDir=*/"", /*HeaderSearchInfo=*/nullptr);
|
|
|
|
|
|
|
|
auto Identifiers = collectIdentifiers(Content, Style);
|
|
|
|
std::vector<RawIdentifier> IdentifierResults;
|
|
|
|
for (const auto &IDAndCount : Identifiers) {
|
|
|
|
RawIdentifier ID;
|
|
|
|
ID.Name = IDAndCount.first();
|
|
|
|
ID.References = IDAndCount.second;
|
|
|
|
// Avoid treating typed filter as an identifier.
|
2019-04-26 15:45:49 +08:00
|
|
|
if (ID.Name == HeuristicPrefix.Name)
|
2019-04-11 17:36:36 +08:00
|
|
|
--ID.References;
|
|
|
|
if (ID.References > 0)
|
|
|
|
IdentifierResults.push_back(std::move(ID));
|
|
|
|
}
|
|
|
|
|
2019-04-26 15:45:49 +08:00
|
|
|
// Simplified version of getQueryScopes():
|
|
|
|
// - accessible scopes are determined heuristically.
|
|
|
|
// - all-scopes query if no qualifier was typed (and it's allowed).
|
|
|
|
SpecifiedScope Scopes;
|
|
|
|
Scopes.AccessibleScopes =
|
|
|
|
visibleNamespaces(Content.take_front(Offset), Style);
|
|
|
|
for (std::string &S : Scopes.AccessibleScopes)
|
|
|
|
if (!S.empty())
|
|
|
|
S.append("::"); // visibleNamespaces doesn't include trailing ::.
|
|
|
|
if (HeuristicPrefix.Qualifier.empty())
|
|
|
|
AllScopes = Opts.AllScopes;
|
|
|
|
else if (HeuristicPrefix.Qualifier.startswith("::")) {
|
|
|
|
Scopes.AccessibleScopes = {""};
|
2020-01-29 03:23:46 +08:00
|
|
|
Scopes.UnresolvedQualifier =
|
|
|
|
std::string(HeuristicPrefix.Qualifier.drop_front(2));
|
2019-04-26 15:45:49 +08:00
|
|
|
} else
|
2020-01-29 03:23:46 +08:00
|
|
|
Scopes.UnresolvedQualifier = std::string(HeuristicPrefix.Qualifier);
|
2019-04-26 15:45:49 +08:00
|
|
|
// First scope is the (modified) enclosing scope.
|
|
|
|
QueryScopes = Scopes.scopesForIndexQuery();
|
|
|
|
ScopeProximity.emplace(QueryScopes);
|
|
|
|
|
|
|
|
SymbolSlab IndexResults = Opts.Index ? queryIndex() : SymbolSlab();
|
|
|
|
|
|
|
|
CodeCompleteResult Output = toCodeCompleteResult(mergeResults(
|
|
|
|
/*SemaResults=*/{}, IndexResults, IdentifierResults));
|
2019-05-06 20:03:26 +08:00
|
|
|
Output.RanParser = false;
|
2019-04-26 15:45:49 +08:00
|
|
|
logResults(Output, Tracer);
|
|
|
|
return Output;
|
2019-04-11 17:36:36 +08:00
|
|
|
}
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
private:
|
2019-05-06 18:25:10 +08:00
|
|
|
void populateContextWords(llvm::StringRef Content) {
|
|
|
|
// Take last 3 lines before the completion point.
|
|
|
|
unsigned RangeEnd = HeuristicPrefix.Qualifier.begin() - Content.data(),
|
|
|
|
RangeBegin = RangeEnd;
|
|
|
|
for (size_t I = 0; I < 3 && RangeBegin > 0; ++I) {
|
2019-07-13 04:35:41 +08:00
|
|
|
auto PrevNL = Content.rfind('\n', RangeBegin);
|
2019-05-06 18:25:10 +08:00
|
|
|
if (PrevNL == StringRef::npos) {
|
|
|
|
RangeBegin = 0;
|
|
|
|
break;
|
|
|
|
}
|
2019-07-13 04:35:41 +08:00
|
|
|
RangeBegin = PrevNL;
|
2019-05-06 18:25:10 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ContextWords = collectWords(Content.slice(RangeBegin, RangeEnd));
|
|
|
|
dlog("Completion context words: {0}",
|
|
|
|
llvm::join(ContextWords.keys(), ", "));
|
|
|
|
}
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// 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());
|
|
|
|
// 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()) {
|
2019-04-11 17:36:36 +08:00
|
|
|
ReplacedRange = halfOpenToRange(Recorder->CCSema->getSourceManager(),
|
2018-08-13 16:23:01 +08:00
|
|
|
CodeCompletionRange);
|
|
|
|
} else {
|
|
|
|
const auto &Pos = sourceLocToPosition(
|
|
|
|
Recorder->CCSema->getSourceManager(),
|
|
|
|
Recorder->CCSema->getPreprocessor().getCodeCompletionLoc());
|
2019-04-11 17:36:36 +08:00
|
|
|
ReplacedRange.start = ReplacedRange.end = Pos;
|
2018-08-13 16:23:01 +08:00
|
|
|
}
|
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());
|
2019-04-10 23:16:54 +08:00
|
|
|
std::tie(QueryScopes, AllScopes) = getQueryScopes(
|
|
|
|
Recorder->CCContext, *Recorder->CCSema, HeuristicPrefix, Opts);
|
2018-10-17 19:19:02 +08:00
|
|
|
if (!QueryScopes.empty())
|
|
|
|
ScopeProximity.emplace(QueryScopes);
|
2018-11-26 23:38:01 +08:00
|
|
|
PreferredType =
|
|
|
|
OpaqueType::fromType(Recorder->CCSema->getASTContext(),
|
|
|
|
Recorder->CCContext.getPreferredType());
|
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-10-02 17:42:17 +08:00
|
|
|
// Merge Sema and Index results, score them, and pick the winners.
|
2019-04-11 17:36:36 +08:00
|
|
|
auto Top =
|
|
|
|
mergeResults(Recorder->Results, IndexResults, /*Identifiers*/ {});
|
|
|
|
return toCodeCompleteResult(Top);
|
|
|
|
}
|
|
|
|
|
|
|
|
CodeCompleteResult
|
|
|
|
toCodeCompleteResult(const std::vector<ScoredBundle> &Scored) {
|
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.
|
2019-04-11 17:36:36 +08:00
|
|
|
for (auto &C : Scored) {
|
2018-06-29 22:47:57 +08:00
|
|
|
Output.Completions.push_back(toCodeCompletion(C.first));
|
|
|
|
Output.Completions.back().Score = C.second;
|
2019-04-11 17:36:36 +08:00
|
|
|
Output.Completions.back().CompletionTokenRange = ReplacedRange;
|
2018-06-29 22:47:57 +08:00
|
|
|
}
|
|
|
|
Output.HasMore = Incomplete;
|
2019-04-11 17:36:36 +08:00
|
|
|
Output.Context = CCContextKind;
|
2020-02-10 18:52:42 +08:00
|
|
|
Output.CompletionRange = ReplacedRange;
|
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)
|
2018-09-13 22:27:03 +08:00
|
|
|
Req.Limit = Opts.Limit;
|
2020-01-29 03:23:46 +08:00
|
|
|
Req.Query = std::string(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-09-28 02:46:00 +08:00
|
|
|
Req.AnyScope = AllScopes;
|
2018-07-03 16:09:29 +08:00
|
|
|
// FIXME: we should send multiple weighted paths here.
|
2020-01-29 03:23:46 +08:00
|
|
|
Req.ProximityPaths.push_back(std::string(FileName));
|
2019-02-06 23:36:23 +08:00
|
|
|
if (PreferredType)
|
2020-01-29 03:23:46 +08:00
|
|
|
Req.PreferredTypes.push_back(std::string(PreferredType->raw()));
|
2018-09-10 19:51:05 +08:00
|
|
|
vlog("Code complete: fuzzyFind({0:2})", toJSON(Req));
|
[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-10-02 17:42:17 +08:00
|
|
|
// Merges Sema and Index results where possible, to form CompletionCandidates.
|
2020-01-04 23:28:41 +08:00
|
|
|
// \p Identifiers is raw identifiers that can also be completion candidates.
|
2019-04-11 17:36:36 +08:00
|
|
|
// Identifiers are not merged with results from index or sema.
|
2018-10-02 17:42:17 +08:00
|
|
|
// 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,
|
2019-04-11 17:36:36 +08:00
|
|
|
const SymbolSlab &IndexResults,
|
|
|
|
const std::vector<RawIdentifier> &IdentifierResults) {
|
[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;
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::DenseMap<size_t, size_t> BundleLookup;
|
[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 AddToBundles = [&](const CodeCompletionResult *SemaResult,
|
2019-04-11 17:36:36 +08:00
|
|
|
const Symbol *IndexResult,
|
2019-04-30 18:35:37 +08:00
|
|
|
const RawIdentifier *IdentifierResult) {
|
[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;
|
2019-04-11 17:36:36 +08:00
|
|
|
C.IdentifierResult = IdentifierResult;
|
|
|
|
if (C.IndexResult) {
|
|
|
|
C.Name = 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
|
|
|
C.RankedIncludeHeaders = getRankedIncludes(*C.IndexResult);
|
2019-04-11 17:36:36 +08:00
|
|
|
} else if (C.SemaResult) {
|
|
|
|
C.Name = Recorder->getName(*SemaResult);
|
|
|
|
} else {
|
|
|
|
assert(IdentifierResult);
|
|
|
|
C.Name = IdentifierResult->Name;
|
|
|
|
}
|
2019-04-10 20:15:35 +08:00
|
|
|
if (auto OverloadSet = C.overloadSet(Opts)) {
|
[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 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));
|
|
|
|
}
|
|
|
|
};
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::DenseSet<const Symbol *> UsedIndexResults;
|
2018-01-19 22:34:02 +08:00
|
|
|
auto CorrespondingIndexResult =
|
|
|
|
[&](const CodeCompletionResult &SemaResult) -> const Symbol * {
|
2018-09-06 17:59:37 +08:00
|
|
|
if (auto SymID =
|
|
|
|
getSymbolID(SemaResult, Recorder->CCSema->getSourceManager())) {
|
2018-01-19 22:34:02 +08:00
|
|
|
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.
|
2019-04-11 17:36:36 +08:00
|
|
|
for (auto &SemaResult : SemaResults)
|
2019-04-30 18:35:37 +08:00
|
|
|
AddToBundles(&SemaResult, CorrespondingIndexResult(SemaResult), nullptr);
|
2018-01-19 22:34:02 +08:00
|
|
|
// Now emit any Index-only results.
|
|
|
|
for (const auto &IndexResult : IndexResults) {
|
|
|
|
if (UsedIndexResults.count(&IndexResult))
|
|
|
|
continue;
|
2019-04-30 18:35:37 +08:00
|
|
|
AddToBundles(/*SemaResult=*/nullptr, &IndexResult, nullptr);
|
2018-01-19 22:34:02 +08:00
|
|
|
}
|
2019-04-11 17:36:36 +08:00
|
|
|
// Emit identifier results.
|
|
|
|
for (const auto &Ident : IdentifierResults)
|
|
|
|
AddToBundles(/*SemaResult=*/nullptr, /*IndexResult=*/nullptr, &Ident);
|
[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();
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::Optional<float> fuzzyScore(const CompletionCandidate &C) {
|
2018-06-08 21:32:25 +08:00
|
|
|
// 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;
|
2019-04-11 17:36:36 +08:00
|
|
|
Relevance.Context = CCContextKind;
|
2019-05-06 18:25:10 +08:00
|
|
|
Relevance.Name = Bundle.front().Name;
|
2018-06-06 00:30:25 +08:00
|
|
|
Relevance.Query = SymbolRelevanceSignals::CodeComplete;
|
2018-07-05 16:26:53 +08:00
|
|
|
Relevance.FileProximityMatch = FileProximity.getPointer();
|
2018-10-17 19:19:02 +08:00
|
|
|
if (ScopeProximity)
|
|
|
|
Relevance.ScopeProximityMatch = ScopeProximity.getPointer();
|
2018-11-26 23:38:01 +08:00
|
|
|
if (PreferredType)
|
|
|
|
Relevance.HadContextType = true;
|
2019-05-06 18:25:10 +08:00
|
|
|
Relevance.ContextWords = &ContextWords;
|
2018-09-28 02:46:00 +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
|
|
|
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;
|
2018-11-26 23:38:01 +08:00
|
|
|
if (!Candidate.IndexResult->Type.empty())
|
|
|
|
Relevance.HadSymbolType |= true;
|
|
|
|
if (PreferredType &&
|
|
|
|
PreferredType->raw() == Candidate.IndexResult->Type) {
|
|
|
|
Relevance.TypeMatchesPreferred = 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-11-26 23:38:01 +08:00
|
|
|
if (PreferredType) {
|
|
|
|
if (auto CompletionType = OpaqueType::fromCompletionResult(
|
|
|
|
Recorder->CCSema->getASTContext(), *Candidate.SemaResult)) {
|
|
|
|
Relevance.HadSymbolType |= true;
|
|
|
|
if (PreferredType == CompletionType)
|
|
|
|
Relevance.TypeMatchesPreferred = true;
|
|
|
|
}
|
|
|
|
}
|
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
|
|
|
}
|
2019-04-11 17:36:36 +08:00
|
|
|
if (Candidate.IdentifierResult) {
|
|
|
|
Quality.References = Candidate.IdentifierResult->References;
|
|
|
|
Relevance.Scope = SymbolRelevanceSignals::FileScope;
|
|
|
|
Origin |= SymbolOrigin::Identifier;
|
|
|
|
}
|
[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,
|
2019-01-07 23:45:19 +08:00
|
|
|
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;
|
2019-04-11 17:36:36 +08:00
|
|
|
NSemaAndIndex += bool(Origin & SymbolOrigin::AST) && FromIndex;
|
|
|
|
NIdent += bool(Origin & SymbolOrigin::Identifier);
|
[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) {
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::Optional<CodeCompletionBuilder> Builder;
|
2018-06-29 22:47:57 +08:00
|
|
|
for (const auto &Item : Bundle) {
|
|
|
|
CodeCompletionString *SemaCCS =
|
|
|
|
Item.SemaResult ? Recorder->codeCompletionString(*Item.SemaResult)
|
|
|
|
: nullptr;
|
|
|
|
if (!Builder)
|
2019-04-11 17:36:36 +08:00
|
|
|
Builder.emplace(Recorder ? &Recorder->CCSema->getASTContext() : nullptr,
|
|
|
|
Item, SemaCCS, QueryScopes, *Inserter, FileName,
|
2019-10-28 16:34:21 +08:00
|
|
|
CCContextKind, Opts,
|
|
|
|
/*GenerateSnippets=*/!IsUsingDeclaration);
|
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
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2019-01-03 23:36:18 +08:00
|
|
|
} // namespace
|
|
|
|
|
|
|
|
clang::CodeCompleteOptions CodeCompleteOptions::getClangCompleteOpts() const {
|
|
|
|
clang::CodeCompleteOptions Result;
|
|
|
|
Result.IncludeCodePatterns = EnableSnippets && IncludeCodePatterns;
|
|
|
|
Result.IncludeMacros = IncludeMacros;
|
|
|
|
Result.IncludeGlobals = true;
|
|
|
|
// 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;
|
|
|
|
|
|
|
|
// 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;
|
|
|
|
Result.IncludeFixIts = IncludeFixIts;
|
|
|
|
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2019-06-04 17:36:59 +08:00
|
|
|
CompletionPrefix guessCompletionPrefix(llvm::StringRef Content,
|
|
|
|
unsigned Offset) {
|
2019-04-10 19:50:40 +08:00
|
|
|
assert(Offset <= Content.size());
|
|
|
|
StringRef Rest = Content.take_front(Offset);
|
|
|
|
CompletionPrefix Result;
|
|
|
|
|
|
|
|
// Consume the unqualified name. We only handle ASCII characters.
|
|
|
|
// isIdentifierBody will let us match "0invalid", but we don't mind.
|
|
|
|
while (!Rest.empty() && isIdentifierBody(Rest.back()))
|
|
|
|
Rest = Rest.drop_back();
|
|
|
|
Result.Name = Content.slice(Rest.size(), Offset);
|
|
|
|
|
|
|
|
// Consume qualifiers.
|
|
|
|
while (Rest.consume_back("::") && !Rest.endswith(":")) // reject ::::
|
|
|
|
while (!Rest.empty() && isIdentifierBody(Rest.back()))
|
|
|
|
Rest = Rest.drop_back();
|
|
|
|
Result.Qualifier =
|
|
|
|
Content.slice(Rest.size(), Result.Name.begin() - Content.begin());
|
[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
|
|
|
|
2019-04-10 19:50:40 +08:00
|
|
|
return Result;
|
[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
|
|
|
}
|
|
|
|
|
|
|
|
CodeCompleteResult
|
|
|
|
codeComplete(PathRef FileName, const tooling::CompileCommand &Command,
|
2019-01-07 23:45:19 +08:00
|
|
|
const PreambleData *Preamble, llvm::StringRef Contents,
|
|
|
|
Position Pos, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem> VFS,
|
[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
|
|
|
CodeCompleteOptions Opts, SpeculativeFuzzyFind *SpecFuzzyFind) {
|
2019-04-10 23:16:54 +08:00
|
|
|
auto Offset = positionToOffset(Contents, Pos);
|
|
|
|
if (!Offset) {
|
|
|
|
elog("Code completion position was invalid {0}", Offset.takeError());
|
|
|
|
return CodeCompleteResult();
|
|
|
|
}
|
2019-04-11 17:36:36 +08:00
|
|
|
auto Flow = CodeCompleteFlow(
|
|
|
|
FileName, Preamble ? Preamble->Includes : IncludeStructure(),
|
|
|
|
SpecFuzzyFind, Opts);
|
2019-05-21 21:40:31 +08:00
|
|
|
return (!Preamble || Opts.RunParser == CodeCompleteOptions::NeverParse)
|
|
|
|
? std::move(Flow).runWithoutSema(Contents, *Offset, VFS)
|
|
|
|
: std::move(Flow).run(
|
|
|
|
{FileName, Command, Preamble, Contents, *Offset, VFS});
|
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,
|
2019-01-07 23:45:19 +08:00
|
|
|
const PreambleData *Preamble,
|
|
|
|
llvm::StringRef Contents, Position Pos,
|
|
|
|
llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem> VFS,
|
2018-09-04 00:37:59 +08:00
|
|
|
const SymbolIndex *Index) {
|
2019-04-10 23:16:54 +08:00
|
|
|
auto Offset = positionToOffset(Contents, Pos);
|
|
|
|
if (!Offset) {
|
|
|
|
elog("Code completion position was invalid {0}", Offset.takeError());
|
|
|
|
return SignatureHelp();
|
|
|
|
}
|
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(
|
2019-08-15 07:52:23 +08:00
|
|
|
std::make_unique<SignatureHelpCollector>(Options, Index, Result),
|
2019-04-10 23:16:54 +08:00
|
|
|
Options,
|
|
|
|
{FileName, Command, Preamble, Contents, *Offset, std::move(VFS)});
|
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) {
|
2018-12-03 20:53:19 +08:00
|
|
|
auto InTopLevelScope = [](const NamedDecl &ND) {
|
|
|
|
switch (ND.getDeclContext()->getDeclKind()) {
|
|
|
|
case Decl::TranslationUnit:
|
|
|
|
case Decl::Namespace:
|
|
|
|
case Decl::LinkageSpec:
|
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
};
|
|
|
|
return false;
|
|
|
|
};
|
[clangd] Store explicit template specializations in index for code navigation purposes
Summary:
This introduces ~4k new symbols, and ~10k refs for LLVM. We need that
information for providing better code navigation support:
- When references for a class template is requested, we should return these specializations as well.
- When children of a specialization is requested, we should be able to query for those symbols(instead of just class template)
Number of symbols: 378574 -> 382784
Number of refs: 5098857 -> 5110689
Reviewers: hokein, gribozavr
Reviewed By: gribozavr
Subscribers: nridge, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59083
llvm-svn: 356125
2019-03-14 16:35:17 +08:00
|
|
|
// We only complete symbol's name, which is the same as the name of the
|
|
|
|
// *primary* template in case of template specializations.
|
2019-08-08 15:21:06 +08:00
|
|
|
if (isExplicitTemplateSpecialization(&ND))
|
[clangd] Store explicit template specializations in index for code navigation purposes
Summary:
This introduces ~4k new symbols, and ~10k refs for LLVM. We need that
information for providing better code navigation support:
- When references for a class template is requested, we should return these specializations as well.
- When children of a specialization is requested, we should be able to query for those symbols(instead of just class template)
Number of symbols: 378574 -> 382784
Number of refs: 5098857 -> 5110689
Reviewers: hokein, gribozavr
Reviewed By: gribozavr
Subscribers: nridge, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59083
llvm-svn: 356125
2019-03-14 16:35:17 +08:00
|
|
|
return false;
|
|
|
|
|
2018-12-03 20:53:19 +08:00
|
|
|
if (InTopLevelScope(ND))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (const auto *EnumDecl = dyn_cast<clang::EnumDecl>(ND.getDeclContext()))
|
|
|
|
return InTopLevelScope(*EnumDecl) && !EnumDecl->isScoped();
|
|
|
|
|
|
|
|
return false;
|
[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
|
|
|
}
|
|
|
|
|
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) +
|
2019-01-07 23:45:19 +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;
|
2020-01-29 03:23:46 +08:00
|
|
|
LSP.detail = BundleSize > 1
|
|
|
|
? std::string(llvm::formatv("[{0} overloads]", BundleSize))
|
|
|
|
: ReturnType;
|
2018-09-07 02:52:26 +08:00
|
|
|
LSP.deprecated = Deprecated;
|
[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};
|
2018-09-05 16:01:37 +08:00
|
|
|
// Merge continuous additionalTextEdits into main edit. The main motivation
|
2018-08-13 16:23:01 +08:00
|
|
|
// 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) {
|
2019-01-25 23:14:03 +08:00
|
|
|
if (isRangeConsecutive(FixIt.range, LSP.textEdit->range)) {
|
2018-08-13 16:23:01 +08:00
|
|
|
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-09-07 02:52:26 +08:00
|
|
|
|
2020-02-13 21:17:30 +08:00
|
|
|
LSP.score = Score.ExcludingName;
|
|
|
|
|
2018-06-29 22:47:57 +08:00
|
|
|
return LSP;
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const CodeCompletion &C) {
|
2018-07-02 19:13:16 +08:00
|
|
|
// For now just lean on CompletionItem.
|
|
|
|
return OS << C.render(CodeCompleteOptions());
|
|
|
|
}
|
|
|
|
|
2019-01-07 23:45:19 +08:00
|
|
|
llvm::raw_ostream &operator<<(llvm::raw_ostream &OS,
|
|
|
|
const CodeCompleteResult &R) {
|
2018-07-02 19:13:16 +08:00
|
|
|
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
|