2017-12-04 21:49:59 +08:00
|
|
|
//===--- CodeComplete.cpp ---------------------------------------*- C++-*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===---------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// AST-based completions are provided using the completion hooks in Sema.
|
|
|
|
//
|
|
|
|
// Signature help works in a similar way as code completion, but it is simpler
|
|
|
|
// as there are typically fewer candidates.
|
|
|
|
//
|
|
|
|
//===---------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "CodeComplete.h"
|
2017-12-21 01:24:31 +08:00
|
|
|
#include "CodeCompletionStrings.h"
|
2017-12-04 21:49:59 +08:00
|
|
|
#include "Compiler.h"
|
2018-01-13 00:16:09 +08:00
|
|
|
#include "FuzzyMatch.h"
|
2018-05-15 23:29:32 +08:00
|
|
|
#include "Headers.h"
|
2017-12-20 00:50:37 +08:00
|
|
|
#include "Logger.h"
|
[clangd] Extract scoring/ranking logic, and shave yaks.
Summary:
Code completion scoring was embedded in CodeComplete.cpp, which is bad:
- awkward to test. The mechanisms (extracting info from index/sema) can be
unit-tested well, the policy (scoring) should be quantitatively measured.
Neither was easily possible, and debugging was hard.
The intermediate signal struct makes this easier.
- hard to reuse. This is a bug in workspaceSymbols: it just presents the
results in the index order, which is not sorted in practice, it needs to rank
them!
Also, index implementations care about scoring (both query-dependent and
independent) in order to truncate result lists appropriately.
The main yak shaved here is the build() function that had 3 variants across
unit tests is unified in TestTU.h (rather than adding a 4th variant).
Reviewers: ilya-biryukov
Subscribers: klimek, mgorny, ioeric, MaskRay, jkorous, mgrang, cfe-commits
Differential Revision: https://reviews.llvm.org/D46524
llvm-svn: 332378
2018-05-16 01:43:27 +08:00
|
|
|
#include "Quality.h"
|
2018-02-16 22:15:55 +08:00
|
|
|
#include "SourceCode.h"
|
2018-01-31 01:20:54 +08:00
|
|
|
#include "Trace.h"
|
2018-05-15 23:29:32 +08:00
|
|
|
#include "URI.h"
|
2017-12-20 00:50:37 +08:00
|
|
|
#include "index/Index.h"
|
[clangd] Add "member" symbols to the index
Summary:
This adds more symbols to the index:
- member variables and functions
- enum constants in scoped enums
The code completion behavior should remain intact but workspace symbols should
now provide much more useful symbols.
Other symbols should be considered such as the ones in "main files" (files not
being included) but this can be done separately as this introduces its fair
share of problems.
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewers: ioeric, sammccall
Reviewed By: ioeric, sammccall
Subscribers: hokein, sammccall, jkorous, klimek, ilya-biryukov, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44954
llvm-svn: 334017
2018-06-05 22:01:40 +08:00
|
|
|
#include "clang/ASTMatchers/ASTMatchFinder.h"
|
2018-05-16 20:32:49 +08:00
|
|
|
#include "clang/Basic/LangOptions.h"
|
2018-02-16 22:15:55 +08:00
|
|
|
#include "clang/Format/Format.h"
|
2017-12-04 21:49:59 +08:00
|
|
|
#include "clang/Frontend/CompilerInstance.h"
|
|
|
|
#include "clang/Frontend/FrontendActions.h"
|
2018-01-19 22:34:02 +08:00
|
|
|
#include "clang/Index/USRGeneration.h"
|
2017-12-04 21:49:59 +08:00
|
|
|
#include "clang/Sema/CodeCompleteConsumer.h"
|
|
|
|
#include "clang/Sema/Sema.h"
|
2018-02-16 22:15:55 +08:00
|
|
|
#include "clang/Tooling/Core/Replacement.h"
|
2018-01-10 22:44:34 +08:00
|
|
|
#include "llvm/Support/Format.h"
|
2017-12-04 21:49:59 +08:00
|
|
|
#include <queue>
|
|
|
|
|
[clangd] Extract scoring/ranking logic, and shave yaks.
Summary:
Code completion scoring was embedded in CodeComplete.cpp, which is bad:
- awkward to test. The mechanisms (extracting info from index/sema) can be
unit-tested well, the policy (scoring) should be quantitatively measured.
Neither was easily possible, and debugging was hard.
The intermediate signal struct makes this easier.
- hard to reuse. This is a bug in workspaceSymbols: it just presents the
results in the index order, which is not sorted in practice, it needs to rank
them!
Also, index implementations care about scoring (both query-dependent and
independent) in order to truncate result lists appropriately.
The main yak shaved here is the build() function that had 3 variants across
unit tests is unified in TestTU.h (rather than adding a 4th variant).
Reviewers: ilya-biryukov
Subscribers: klimek, mgorny, ioeric, MaskRay, jkorous, mgrang, cfe-commits
Differential Revision: https://reviews.llvm.org/D46524
llvm-svn: 332378
2018-05-16 01:43:27 +08:00
|
|
|
// We log detailed candidate here if you run with -debug-only=codecomplete.
|
|
|
|
#define DEBUG_TYPE "codecomplete"
|
|
|
|
|
2017-12-04 21:49:59 +08:00
|
|
|
namespace clang {
|
|
|
|
namespace clangd {
|
|
|
|
namespace {
|
|
|
|
|
2017-12-20 00:50:37 +08:00
|
|
|
CompletionItemKind toCompletionItemKind(CXCursorKind CursorKind) {
|
2017-12-04 21:49:59 +08:00
|
|
|
switch (CursorKind) {
|
|
|
|
case CXCursor_MacroInstantiation:
|
|
|
|
case CXCursor_MacroDefinition:
|
|
|
|
return CompletionItemKind::Text;
|
|
|
|
case CXCursor_CXXMethod:
|
2017-12-20 00:50:37 +08:00
|
|
|
case CXCursor_Destructor:
|
2017-12-04 21:49:59 +08:00
|
|
|
return CompletionItemKind::Method;
|
|
|
|
case CXCursor_FunctionDecl:
|
|
|
|
case CXCursor_FunctionTemplate:
|
|
|
|
return CompletionItemKind::Function;
|
|
|
|
case CXCursor_Constructor:
|
|
|
|
return CompletionItemKind::Constructor;
|
|
|
|
case CXCursor_FieldDecl:
|
|
|
|
return CompletionItemKind::Field;
|
|
|
|
case CXCursor_VarDecl:
|
|
|
|
case CXCursor_ParmDecl:
|
|
|
|
return CompletionItemKind::Variable;
|
2017-12-20 00:50:37 +08:00
|
|
|
// FIXME(ioeric): use LSP struct instead of class when it is suppoted in the
|
|
|
|
// protocol.
|
2017-12-04 21:49:59 +08:00
|
|
|
case CXCursor_StructDecl:
|
2017-12-20 00:50:37 +08:00
|
|
|
case CXCursor_ClassDecl:
|
2017-12-04 21:49:59 +08:00
|
|
|
case CXCursor_UnionDecl:
|
|
|
|
case CXCursor_ClassTemplate:
|
|
|
|
case CXCursor_ClassTemplatePartialSpecialization:
|
|
|
|
return CompletionItemKind::Class;
|
|
|
|
case CXCursor_Namespace:
|
|
|
|
case CXCursor_NamespaceAlias:
|
|
|
|
case CXCursor_NamespaceRef:
|
|
|
|
return CompletionItemKind::Module;
|
|
|
|
case CXCursor_EnumConstantDecl:
|
|
|
|
return CompletionItemKind::Value;
|
|
|
|
case CXCursor_EnumDecl:
|
|
|
|
return CompletionItemKind::Enum;
|
2017-12-20 00:50:37 +08:00
|
|
|
// FIXME(ioeric): figure out whether reference is the right type for aliases.
|
2017-12-04 21:49:59 +08:00
|
|
|
case CXCursor_TypeAliasDecl:
|
|
|
|
case CXCursor_TypeAliasTemplateDecl:
|
|
|
|
case CXCursor_TypedefDecl:
|
|
|
|
case CXCursor_MemberRef:
|
|
|
|
case CXCursor_TypeRef:
|
|
|
|
return CompletionItemKind::Reference;
|
|
|
|
default:
|
|
|
|
return CompletionItemKind::Missing;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-12-20 00:50:37 +08:00
|
|
|
CompletionItemKind
|
|
|
|
toCompletionItemKind(CodeCompletionResult::ResultKind ResKind,
|
|
|
|
CXCursorKind CursorKind) {
|
2017-12-04 21:49:59 +08:00
|
|
|
switch (ResKind) {
|
|
|
|
case CodeCompletionResult::RK_Declaration:
|
2017-12-20 00:50:37 +08:00
|
|
|
return toCompletionItemKind(CursorKind);
|
2017-12-04 21:49:59 +08:00
|
|
|
case CodeCompletionResult::RK_Keyword:
|
|
|
|
return CompletionItemKind::Keyword;
|
|
|
|
case CodeCompletionResult::RK_Macro:
|
|
|
|
return CompletionItemKind::Text; // unfortunately, there's no 'Macro'
|
|
|
|
// completion items in LSP.
|
|
|
|
case CodeCompletionResult::RK_Pattern:
|
|
|
|
return CompletionItemKind::Snippet;
|
|
|
|
}
|
|
|
|
llvm_unreachable("Unhandled CodeCompletionResult::ResultKind.");
|
|
|
|
}
|
|
|
|
|
2017-12-20 00:50:37 +08:00
|
|
|
CompletionItemKind toCompletionItemKind(index::SymbolKind Kind) {
|
|
|
|
using SK = index::SymbolKind;
|
|
|
|
switch (Kind) {
|
|
|
|
case SK::Unknown:
|
|
|
|
return CompletionItemKind::Missing;
|
|
|
|
case SK::Module:
|
|
|
|
case SK::Namespace:
|
|
|
|
case SK::NamespaceAlias:
|
|
|
|
return CompletionItemKind::Module;
|
|
|
|
case SK::Macro:
|
|
|
|
return CompletionItemKind::Text;
|
|
|
|
case SK::Enum:
|
|
|
|
return CompletionItemKind::Enum;
|
|
|
|
// FIXME(ioeric): use LSP struct instead of class when it is suppoted in the
|
|
|
|
// protocol.
|
|
|
|
case SK::Struct:
|
|
|
|
case SK::Class:
|
|
|
|
case SK::Protocol:
|
|
|
|
case SK::Extension:
|
|
|
|
case SK::Union:
|
|
|
|
return CompletionItemKind::Class;
|
|
|
|
// FIXME(ioeric): figure out whether reference is the right type for aliases.
|
|
|
|
case SK::TypeAlias:
|
|
|
|
case SK::Using:
|
|
|
|
return CompletionItemKind::Reference;
|
|
|
|
case SK::Function:
|
|
|
|
// FIXME(ioeric): this should probably be an operator. This should be fixed
|
|
|
|
// when `Operator` is support type in the protocol.
|
|
|
|
case SK::ConversionFunction:
|
|
|
|
return CompletionItemKind::Function;
|
|
|
|
case SK::Variable:
|
|
|
|
case SK::Parameter:
|
|
|
|
return CompletionItemKind::Variable;
|
|
|
|
case SK::Field:
|
|
|
|
return CompletionItemKind::Field;
|
|
|
|
// FIXME(ioeric): use LSP enum constant when it is supported in the protocol.
|
|
|
|
case SK::EnumConstant:
|
|
|
|
return CompletionItemKind::Value;
|
|
|
|
case SK::InstanceMethod:
|
|
|
|
case SK::ClassMethod:
|
|
|
|
case SK::StaticMethod:
|
|
|
|
case SK::Destructor:
|
|
|
|
return CompletionItemKind::Method;
|
|
|
|
case SK::InstanceProperty:
|
|
|
|
case SK::ClassProperty:
|
|
|
|
case SK::StaticProperty:
|
|
|
|
return CompletionItemKind::Property;
|
|
|
|
case SK::Constructor:
|
|
|
|
return CompletionItemKind::Constructor;
|
|
|
|
}
|
|
|
|
llvm_unreachable("Unhandled clang::index::SymbolKind.");
|
|
|
|
}
|
|
|
|
|
2017-12-04 21:49:59 +08:00
|
|
|
/// Get the optional chunk as a string. This function is possibly recursive.
|
|
|
|
///
|
|
|
|
/// The parameter info for each parameter is appended to the Parameters.
|
|
|
|
std::string
|
|
|
|
getOptionalParameters(const CodeCompletionString &CCS,
|
|
|
|
std::vector<ParameterInformation> &Parameters) {
|
|
|
|
std::string Result;
|
|
|
|
for (const auto &Chunk : CCS) {
|
|
|
|
switch (Chunk.Kind) {
|
|
|
|
case CodeCompletionString::CK_Optional:
|
|
|
|
assert(Chunk.Optional &&
|
|
|
|
"Expected the optional code completion string to be non-null.");
|
|
|
|
Result += getOptionalParameters(*Chunk.Optional, Parameters);
|
|
|
|
break;
|
|
|
|
case CodeCompletionString::CK_VerticalSpace:
|
|
|
|
break;
|
|
|
|
case CodeCompletionString::CK_Placeholder:
|
|
|
|
// A string that acts as a placeholder for, e.g., a function call
|
|
|
|
// argument.
|
|
|
|
// Intentional fallthrough here.
|
|
|
|
case CodeCompletionString::CK_CurrentParameter: {
|
|
|
|
// A piece of text that describes the parameter that corresponds to
|
|
|
|
// the code-completion location within a function call, message send,
|
|
|
|
// macro invocation, etc.
|
|
|
|
Result += Chunk.Text;
|
|
|
|
ParameterInformation Info;
|
|
|
|
Info.label = Chunk.Text;
|
|
|
|
Parameters.push_back(std::move(Info));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
Result += Chunk.Text;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2018-05-15 23:29:32 +08:00
|
|
|
/// Creates a `HeaderFile` from \p Header which can be either a URI or a literal
|
|
|
|
/// include.
|
|
|
|
static llvm::Expected<HeaderFile> toHeaderFile(StringRef Header,
|
|
|
|
llvm::StringRef HintPath) {
|
|
|
|
if (isLiteralInclude(Header))
|
|
|
|
return HeaderFile{Header.str(), /*Verbatim=*/true};
|
|
|
|
auto U = URI::parse(Header);
|
|
|
|
if (!U)
|
|
|
|
return U.takeError();
|
|
|
|
|
|
|
|
auto IncludePath = URI::includeSpelling(*U);
|
|
|
|
if (!IncludePath)
|
|
|
|
return IncludePath.takeError();
|
|
|
|
if (!IncludePath->empty())
|
|
|
|
return HeaderFile{std::move(*IncludePath), /*Verbatim=*/true};
|
|
|
|
|
|
|
|
auto Resolved = URI::resolve(*U, HintPath);
|
|
|
|
if (!Resolved)
|
|
|
|
return Resolved.takeError();
|
|
|
|
return HeaderFile{std::move(*Resolved), /*Verbatim=*/false};
|
|
|
|
}
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
/// A code completion result, in clang-native form.
|
|
|
|
/// It may be promoted to a CompletionItem if it's among the top-ranked results.
|
|
|
|
struct CompletionCandidate {
|
|
|
|
llvm::StringRef Name; // Used for filtering and sorting.
|
|
|
|
// We may have a result from Sema, from the index, or both.
|
|
|
|
const CodeCompletionResult *SemaResult = nullptr;
|
|
|
|
const Symbol *IndexResult = nullptr;
|
2017-12-04 21:49:59 +08:00
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// Builds an LSP completion item.
|
2018-05-15 23:29:32 +08:00
|
|
|
CompletionItem build(StringRef FileName, const CompletionItemScores &Scores,
|
2018-01-19 22:34:02 +08:00
|
|
|
const CodeCompleteOptions &Opts,
|
2018-05-15 23:29:32 +08:00
|
|
|
CodeCompletionString *SemaCCS,
|
2018-05-16 20:32:44 +08:00
|
|
|
const IncludeInserter *Includes,
|
|
|
|
llvm::StringRef SemaDocComment) const {
|
2018-01-19 22:34:02 +08:00
|
|
|
assert(bool(SemaResult) == bool(SemaCCS));
|
|
|
|
CompletionItem I;
|
2018-05-30 17:03:39 +08:00
|
|
|
bool ShouldInsertInclude = true;
|
2018-01-19 22:34:02 +08:00
|
|
|
if (SemaResult) {
|
|
|
|
I.kind = toCompletionItemKind(SemaResult->Kind, SemaResult->CursorKind);
|
|
|
|
getLabelAndInsertText(*SemaCCS, &I.label, &I.insertText,
|
|
|
|
Opts.EnableSnippets);
|
|
|
|
I.filterText = getFilterText(*SemaCCS);
|
2018-05-16 20:32:44 +08:00
|
|
|
I.documentation = formatDocumentation(*SemaCCS, SemaDocComment);
|
2018-01-19 22:34:02 +08:00
|
|
|
I.detail = getDetail(*SemaCCS);
|
2018-05-30 17:03:39 +08:00
|
|
|
// Avoid inserting new #include if the declaration is found in the current
|
|
|
|
// file e.g. the symbol is forward declared.
|
|
|
|
if (SemaResult->Kind == CodeCompletionResult::RK_Declaration) {
|
|
|
|
if (const auto *D = SemaResult->getDeclaration()) {
|
|
|
|
const auto &SM = D->getASTContext().getSourceManager();
|
|
|
|
ShouldInsertInclude =
|
|
|
|
ShouldInsertInclude &&
|
|
|
|
std::none_of(D->redecls_begin(), D->redecls_end(),
|
|
|
|
[&SM](const Decl *RD) {
|
|
|
|
return SM.isInMainFile(
|
|
|
|
SM.getExpansionLoc(RD->getLocStart()));
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
2018-01-19 22:34:02 +08:00
|
|
|
}
|
|
|
|
if (IndexResult) {
|
|
|
|
if (I.kind == CompletionItemKind::Missing)
|
|
|
|
I.kind = toCompletionItemKind(IndexResult->SymInfo.Kind);
|
|
|
|
// FIXME: reintroduce a way to show the index source for debugging.
|
|
|
|
if (I.label.empty())
|
|
|
|
I.label = IndexResult->CompletionLabel;
|
|
|
|
if (I.filterText.empty())
|
|
|
|
I.filterText = IndexResult->Name;
|
|
|
|
|
|
|
|
// FIXME(ioeric): support inserting/replacing scope qualifiers.
|
|
|
|
if (I.insertText.empty())
|
|
|
|
I.insertText = Opts.EnableSnippets
|
|
|
|
? IndexResult->CompletionSnippetInsertText
|
|
|
|
: IndexResult->CompletionPlainInsertText;
|
|
|
|
|
|
|
|
if (auto *D = IndexResult->Detail) {
|
|
|
|
if (I.documentation.empty())
|
|
|
|
I.documentation = D->Documentation;
|
|
|
|
if (I.detail.empty())
|
|
|
|
I.detail = D->CompletionDetail;
|
2018-05-30 17:03:39 +08:00
|
|
|
if (ShouldInsertInclude && Includes && !D->IncludeHeader.empty()) {
|
2018-05-15 23:29:32 +08:00
|
|
|
auto Edit = [&]() -> Expected<Optional<TextEdit>> {
|
|
|
|
auto ResolvedDeclaring = toHeaderFile(
|
|
|
|
IndexResult->CanonicalDeclaration.FileURI, FileName);
|
|
|
|
if (!ResolvedDeclaring)
|
|
|
|
return ResolvedDeclaring.takeError();
|
|
|
|
auto ResolvedInserted = toHeaderFile(D->IncludeHeader, FileName);
|
|
|
|
if (!ResolvedInserted)
|
|
|
|
return ResolvedInserted.takeError();
|
|
|
|
return Includes->insert(*ResolvedDeclaring, *ResolvedInserted);
|
|
|
|
}();
|
|
|
|
if (!Edit) {
|
|
|
|
std::string ErrMsg =
|
|
|
|
("Failed to generate include insertion edits for adding header "
|
|
|
|
"(FileURI=\"" +
|
|
|
|
IndexResult->CanonicalDeclaration.FileURI +
|
|
|
|
"\", IncludeHeader=\"" + D->IncludeHeader + "\") into " +
|
|
|
|
FileName)
|
|
|
|
.str();
|
|
|
|
log(ErrMsg + ":" + llvm::toString(Edit.takeError()));
|
|
|
|
} else if (*Edit) {
|
|
|
|
I.additionalTextEdits = {std::move(**Edit)};
|
|
|
|
}
|
|
|
|
}
|
2018-01-19 22:34:02 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
I.scoreInfo = Scores;
|
|
|
|
I.sortText = sortText(Scores.finalScore, Name);
|
|
|
|
I.insertTextFormat = Opts.EnableSnippets ? InsertTextFormat::Snippet
|
|
|
|
: InsertTextFormat::PlainText;
|
|
|
|
return I;
|
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
|
|
|
using ScoredCandidate = std::pair<CompletionCandidate, CompletionItemScores>;
|
2017-12-04 21:49:59 +08:00
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// Determine the symbol ID for a Sema code completion result, if possible.
|
|
|
|
llvm::Optional<SymbolID> getSymbolID(const CodeCompletionResult &R) {
|
|
|
|
switch (R.Kind) {
|
|
|
|
case CodeCompletionResult::RK_Declaration:
|
|
|
|
case CodeCompletionResult::RK_Pattern: {
|
|
|
|
llvm::SmallString<128> USR;
|
|
|
|
if (/*Ignore=*/clang::index::generateUSRForDecl(R.Declaration, USR))
|
|
|
|
return None;
|
|
|
|
return SymbolID(USR);
|
|
|
|
}
|
|
|
|
case CodeCompletionResult::RK_Macro:
|
|
|
|
// FIXME: Macros do have USRs, but the CCR doesn't contain enough info.
|
|
|
|
case CodeCompletionResult::RK_Keyword:
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
llvm_unreachable("unknown CodeCompletionResult kind");
|
|
|
|
}
|
|
|
|
|
2018-01-23 19:37:26 +08:00
|
|
|
// Scopes of the paritial identifier we're trying to complete.
|
|
|
|
// It is used when we query the index for more completion results.
|
2017-12-20 00:50:37 +08:00
|
|
|
struct SpecifiedScope {
|
2018-01-23 19:37:26 +08:00
|
|
|
// The scopes we should look in, determined by Sema.
|
|
|
|
//
|
|
|
|
// If the qualifier was fully resolved, we look for completions in these
|
|
|
|
// scopes; if there is an unresolved part of the qualifier, it should be
|
|
|
|
// resolved within these scopes.
|
|
|
|
//
|
|
|
|
// Examples of qualified completion:
|
|
|
|
//
|
|
|
|
// "::vec" => {""}
|
|
|
|
// "using namespace std; ::vec^" => {"", "std::"}
|
|
|
|
// "namespace ns {using namespace std;} ns::^" => {"ns::", "std::"}
|
|
|
|
// "std::vec^" => {""} // "std" unresolved
|
|
|
|
//
|
|
|
|
// Examples of unqualified completion:
|
|
|
|
//
|
|
|
|
// "vec^" => {""}
|
|
|
|
// "using namespace std; vec^" => {"", "std::"}
|
|
|
|
// "using namespace std; namespace ns { vec^ }" => {"ns::", "std::", ""}
|
|
|
|
//
|
|
|
|
// "" for global namespace, "ns::" for normal namespace.
|
|
|
|
std::vector<std::string> AccessibleScopes;
|
|
|
|
// The full scope qualifier as typed by the user (without the leading "::").
|
|
|
|
// Set if the qualifier is not fully resolved by Sema.
|
|
|
|
llvm::Optional<std::string> UnresolvedQualifier;
|
|
|
|
|
|
|
|
// Construct scopes being queried in indexes.
|
|
|
|
// This method format the scopes to match the index request representation.
|
|
|
|
std::vector<std::string> scopesForIndexQuery() {
|
|
|
|
std::vector<std::string> Results;
|
|
|
|
for (llvm::StringRef AS : AccessibleScopes) {
|
|
|
|
Results.push_back(AS);
|
|
|
|
if (UnresolvedQualifier)
|
|
|
|
Results.back() += *UnresolvedQualifier;
|
|
|
|
}
|
|
|
|
return Results;
|
2018-01-19 22:34:02 +08:00
|
|
|
}
|
2017-12-20 00:50:37 +08:00
|
|
|
};
|
|
|
|
|
2018-01-23 19:37:26 +08:00
|
|
|
// Get all scopes that will be queried in indexes.
|
|
|
|
std::vector<std::string> getQueryScopes(CodeCompletionContext &CCContext,
|
2018-05-29 19:50:51 +08:00
|
|
|
const SourceManager &SM) {
|
|
|
|
auto GetAllAccessibleScopes = [](CodeCompletionContext &CCContext) {
|
2018-01-23 19:37:26 +08:00
|
|
|
SpecifiedScope Info;
|
2018-05-29 19:50:51 +08:00
|
|
|
for (auto *Context : CCContext.getVisitedContexts()) {
|
2018-01-23 19:37:26 +08:00
|
|
|
if (isa<TranslationUnitDecl>(Context))
|
|
|
|
Info.AccessibleScopes.push_back(""); // global namespace
|
2018-05-29 19:50:51 +08:00
|
|
|
else if (const auto *NS = dyn_cast<NamespaceDecl>(Context))
|
2018-01-23 19:37:26 +08:00
|
|
|
Info.AccessibleScopes.push_back(NS->getQualifiedNameAsString() + "::");
|
|
|
|
}
|
|
|
|
return Info;
|
|
|
|
};
|
|
|
|
|
|
|
|
auto SS = CCContext.getCXXScopeSpecifier();
|
|
|
|
|
|
|
|
// Unqualified completion (e.g. "vec^").
|
|
|
|
if (!SS) {
|
|
|
|
// FIXME: Once we can insert namespace qualifiers and use the in-scope
|
|
|
|
// namespaces for scoring, search in all namespaces.
|
|
|
|
// FIXME: Capture scopes and use for scoring, for example,
|
|
|
|
// "using namespace std; namespace foo {v^}" =>
|
|
|
|
// foo::value > std::vector > boost::variant
|
|
|
|
return GetAllAccessibleScopes(CCContext).scopesForIndexQuery();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Qualified completion ("std::vec^"), we have two cases depending on whether
|
|
|
|
// the qualifier can be resolved by Sema.
|
|
|
|
if ((*SS)->isValid()) { // Resolved qualifier.
|
|
|
|
return GetAllAccessibleScopes(CCContext).scopesForIndexQuery();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Unresolved qualifier.
|
|
|
|
// FIXME: When Sema can resolve part of a scope chain (e.g.
|
|
|
|
// "known::unknown::id"), we should expand the known part ("known::") rather
|
|
|
|
// than treating the whole thing as unknown.
|
|
|
|
SpecifiedScope Info;
|
|
|
|
Info.AccessibleScopes.push_back(""); // global namespace
|
|
|
|
|
|
|
|
Info.UnresolvedQualifier =
|
2018-05-29 19:50:51 +08:00
|
|
|
Lexer::getSourceText(CharSourceRange::getCharRange((*SS)->getRange()), SM,
|
|
|
|
clang::LangOptions())
|
|
|
|
.ltrim("::");
|
2018-01-23 19:37:26 +08:00
|
|
|
// Sema excludes the trailing "::".
|
|
|
|
if (!Info.UnresolvedQualifier->empty())
|
|
|
|
*Info.UnresolvedQualifier += "::";
|
|
|
|
|
|
|
|
return Info.scopesForIndexQuery();
|
|
|
|
}
|
|
|
|
|
2018-05-24 19:20:19 +08:00
|
|
|
// Should we perform index-based completion in a context of the specified kind?
|
|
|
|
// FIXME: consider allowing completion, but restricting the result types.
|
|
|
|
bool contextAllowsIndex(enum CodeCompletionContext::Kind K) {
|
|
|
|
switch (K) {
|
|
|
|
case CodeCompletionContext::CCC_TopLevel:
|
|
|
|
case CodeCompletionContext::CCC_ObjCInterface:
|
|
|
|
case CodeCompletionContext::CCC_ObjCImplementation:
|
|
|
|
case CodeCompletionContext::CCC_ObjCIvarList:
|
|
|
|
case CodeCompletionContext::CCC_ClassStructUnion:
|
|
|
|
case CodeCompletionContext::CCC_Statement:
|
|
|
|
case CodeCompletionContext::CCC_Expression:
|
|
|
|
case CodeCompletionContext::CCC_ObjCMessageReceiver:
|
|
|
|
case CodeCompletionContext::CCC_EnumTag:
|
|
|
|
case CodeCompletionContext::CCC_UnionTag:
|
|
|
|
case CodeCompletionContext::CCC_ClassOrStructTag:
|
|
|
|
case CodeCompletionContext::CCC_ObjCProtocolName:
|
|
|
|
case CodeCompletionContext::CCC_Namespace:
|
|
|
|
case CodeCompletionContext::CCC_Type:
|
|
|
|
case CodeCompletionContext::CCC_Name: // FIXME: why does ns::^ give this?
|
|
|
|
case CodeCompletionContext::CCC_PotentiallyQualifiedName:
|
|
|
|
case CodeCompletionContext::CCC_ParenthesizedExpression:
|
|
|
|
case CodeCompletionContext::CCC_ObjCInterfaceName:
|
|
|
|
case CodeCompletionContext::CCC_ObjCCategoryName:
|
|
|
|
return true;
|
|
|
|
case CodeCompletionContext::CCC_Other: // Be conservative.
|
|
|
|
case CodeCompletionContext::CCC_OtherWithMacros:
|
|
|
|
case CodeCompletionContext::CCC_DotMemberAccess:
|
|
|
|
case CodeCompletionContext::CCC_ArrowMemberAccess:
|
|
|
|
case CodeCompletionContext::CCC_ObjCPropertyAccess:
|
|
|
|
case CodeCompletionContext::CCC_MacroName:
|
|
|
|
case CodeCompletionContext::CCC_MacroNameUse:
|
|
|
|
case CodeCompletionContext::CCC_PreprocessorExpression:
|
|
|
|
case CodeCompletionContext::CCC_PreprocessorDirective:
|
|
|
|
case CodeCompletionContext::CCC_NaturalLanguage:
|
|
|
|
case CodeCompletionContext::CCC_SelectorName:
|
|
|
|
case CodeCompletionContext::CCC_TypeQualifiers:
|
|
|
|
case CodeCompletionContext::CCC_ObjCInstanceMessage:
|
|
|
|
case CodeCompletionContext::CCC_ObjCClassMessage:
|
|
|
|
case CodeCompletionContext::CCC_Recovery:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
llvm_unreachable("unknown code completion context");
|
|
|
|
}
|
|
|
|
|
2018-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,
|
|
|
|
UniqueFunction<void()> ResultsCallback)
|
2018-01-19 22:34:02 +08:00
|
|
|
: CodeCompleteConsumer(Opts.getClangCompleteOpts(),
|
2017-12-04 21:49:59 +08:00
|
|
|
/*OutputIsBinary=*/false),
|
2018-01-19 22:34:02 +08:00
|
|
|
CCContext(CodeCompletionContext::CCC_Other), Opts(Opts),
|
|
|
|
CCAllocator(std::make_shared<GlobalCodeCompletionAllocator>()),
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
CCTUInfo(CCAllocator), ResultsCallback(std::move(ResultsCallback)) {
|
|
|
|
assert(this->ResultsCallback);
|
|
|
|
}
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
std::vector<CodeCompletionResult> Results;
|
|
|
|
CodeCompletionContext CCContext;
|
|
|
|
Sema *CCSema = nullptr; // Sema that created the results.
|
|
|
|
// FIXME: Sema is scary. Can we store ASTContext and Preprocessor, instead?
|
|
|
|
|
|
|
|
void ProcessCodeCompleteResults(class Sema &S, CodeCompletionContext Context,
|
|
|
|
CodeCompletionResult *InResults,
|
2017-12-04 21:49:59 +08:00
|
|
|
unsigned NumResults) override final {
|
2018-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) {
|
|
|
|
log(llvm::formatv(
|
|
|
|
"Multiple code complete callbacks (parser backtracked?). "
|
|
|
|
"Dropping results from context {0}, keeping results from {1}.",
|
2018-05-24 19:20:19 +08:00
|
|
|
getCompletionKindString(Context.getKind()),
|
|
|
|
getCompletionKindString(this->CCContext.getKind())));
|
2018-03-16 23:23:44 +08:00
|
|
|
return;
|
|
|
|
}
|
2018-01-19 22:34:02 +08:00
|
|
|
// Record the completion context.
|
|
|
|
CCSema = &S;
|
|
|
|
CCContext = Context;
|
2017-12-20 00:50:37 +08:00
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// Retain the results we might want.
|
2017-12-04 21:49:59 +08:00
|
|
|
for (unsigned I = 0; I < NumResults; ++I) {
|
2018-01-19 22:34:02 +08:00
|
|
|
auto &Result = InResults[I];
|
|
|
|
// Drop hidden items which cannot be found by lookup after completion.
|
|
|
|
// Exception: some items can be named by using a qualifier.
|
2018-01-10 21:51:09 +08:00
|
|
|
if (Result.Hidden && (!Result.Qualifier || Result.QualifierIsInformative))
|
|
|
|
continue;
|
2018-01-19 22:34:02 +08:00
|
|
|
if (!Opts.IncludeIneligibleResults &&
|
2017-12-04 21:49:59 +08:00
|
|
|
(Result.Availability == CXAvailability_NotAvailable ||
|
|
|
|
Result.Availability == CXAvailability_NotAccessible))
|
|
|
|
continue;
|
2018-01-23 05:05:00 +08:00
|
|
|
// Destructor completion is rarely useful, and works inconsistently.
|
|
|
|
// (s.^ completes ~string, but s.~st^ is an error).
|
|
|
|
if (dyn_cast_or_null<CXXDestructorDecl>(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).
|
|
|
|
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;
|
[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
|
|
|
UniqueFunction<void()> ResultsCallback;
|
2018-01-19 22:34:02 +08:00
|
|
|
};
|
2017-12-21 01:24:31 +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
|
|
|
struct ScoredCandidateGreater {
|
|
|
|
bool operator()(const ScoredCandidate &L, const ScoredCandidate &R) {
|
2018-01-19 22:34:02 +08:00
|
|
|
if (L.second.finalScore != R.second.finalScore)
|
|
|
|
return L.second.finalScore > R.second.finalScore;
|
|
|
|
return L.first.Name < R.first.Name; // Earlier name is better.
|
2017-12-04 21:49:59 +08:00
|
|
|
}
|
2018-01-19 22:34:02 +08:00
|
|
|
};
|
2017-12-04 21:49:59 +08:00
|
|
|
|
|
|
|
class SignatureHelpCollector final : public CodeCompleteConsumer {
|
|
|
|
|
|
|
|
public:
|
|
|
|
SignatureHelpCollector(const clang::CodeCompleteOptions &CodeCompleteOpts,
|
|
|
|
SignatureHelp &SigHelp)
|
|
|
|
: CodeCompleteConsumer(CodeCompleteOpts, /*OutputIsBinary=*/false),
|
|
|
|
SigHelp(SigHelp),
|
|
|
|
Allocator(std::make_shared<clang::GlobalCodeCompletionAllocator>()),
|
|
|
|
CCTUInfo(Allocator) {}
|
|
|
|
|
|
|
|
void ProcessOverloadCandidates(Sema &S, unsigned CurrentArg,
|
|
|
|
OverloadCandidate *Candidates,
|
|
|
|
unsigned NumCandidates) override {
|
|
|
|
SigHelp.signatures.reserve(NumCandidates);
|
|
|
|
// 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) {
|
|
|
|
const auto &Candidate = Candidates[I];
|
|
|
|
const auto *CCS = Candidate.CreateSignatureString(
|
|
|
|
CurrentArg, S, *Allocator, CCTUInfo, true);
|
|
|
|
assert(CCS && "Expected the CodeCompletionString to be non-null");
|
2018-05-24 22:49:23 +08:00
|
|
|
// FIXME: for headers, we need to get a comment from the index.
|
2018-05-16 20:32:44 +08:00
|
|
|
SigHelp.signatures.push_back(ProcessOverloadCandidate(
|
|
|
|
Candidate, *CCS,
|
2018-05-24 22:49:23 +08:00
|
|
|
getParameterDocComment(S.getASTContext(), Candidate, CurrentArg,
|
2018-05-29 19:50:51 +08:00
|
|
|
/*CommentsFromHeaders=*/false)));
|
2017-12-04 21:49:59 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
GlobalCodeCompletionAllocator &getAllocator() override { return *Allocator; }
|
|
|
|
|
|
|
|
CodeCompletionTUInfo &getCodeCompletionTUInfo() override { return CCTUInfo; }
|
|
|
|
|
|
|
|
private:
|
2017-12-21 01:24:31 +08:00
|
|
|
// FIXME(ioeric): consider moving CodeCompletionString logic here to
|
|
|
|
// CompletionString.h.
|
2017-12-04 21:49:59 +08:00
|
|
|
SignatureInformation
|
|
|
|
ProcessOverloadCandidate(const OverloadCandidate &Candidate,
|
2018-05-16 20:32:44 +08:00
|
|
|
const CodeCompletionString &CCS,
|
|
|
|
llvm::StringRef DocComment) const {
|
2017-12-04 21:49:59 +08:00
|
|
|
SignatureInformation Result;
|
|
|
|
const char *ReturnType = nullptr;
|
|
|
|
|
2018-05-16 20:32:44 +08:00
|
|
|
Result.documentation = formatDocumentation(CCS, DocComment);
|
2017-12-04 21:49:59 +08:00
|
|
|
|
|
|
|
for (const auto &Chunk : CCS) {
|
|
|
|
switch (Chunk.Kind) {
|
|
|
|
case CodeCompletionString::CK_ResultType:
|
|
|
|
// A piece of text that describes the type of an entity or,
|
|
|
|
// for functions and methods, the return type.
|
|
|
|
assert(!ReturnType && "Unexpected CK_ResultType");
|
|
|
|
ReturnType = Chunk.Text;
|
|
|
|
break;
|
|
|
|
case CodeCompletionString::CK_Placeholder:
|
|
|
|
// A string that acts as a placeholder for, e.g., a function call
|
|
|
|
// argument.
|
|
|
|
// Intentional fallthrough here.
|
|
|
|
case CodeCompletionString::CK_CurrentParameter: {
|
|
|
|
// A piece of text that describes the parameter that corresponds to
|
|
|
|
// the code-completion location within a function call, message send,
|
|
|
|
// macro invocation, etc.
|
|
|
|
Result.label += Chunk.Text;
|
|
|
|
ParameterInformation Info;
|
|
|
|
Info.label = Chunk.Text;
|
|
|
|
Result.parameters.push_back(std::move(Info));
|
|
|
|
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.");
|
|
|
|
Result.label +=
|
|
|
|
getOptionalParameters(*Chunk.Optional, Result.parameters);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case CodeCompletionString::CK_VerticalSpace:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
Result.label += Chunk.Text;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (ReturnType) {
|
|
|
|
Result.label += " -> ";
|
|
|
|
Result.label += ReturnType;
|
|
|
|
}
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
|
|
|
SignatureHelp &SigHelp;
|
|
|
|
std::shared_ptr<clang::GlobalCodeCompletionAllocator> Allocator;
|
|
|
|
CodeCompletionTUInfo CCTUInfo;
|
|
|
|
|
|
|
|
}; // SignatureHelpCollector
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
struct SemaCompleteInput {
|
|
|
|
PathRef FileName;
|
|
|
|
const tooling::CompileCommand &Command;
|
|
|
|
PrecompiledPreamble const *Preamble;
|
2018-05-15 23:29:32 +08:00
|
|
|
const std::vector<Inclusion> &PreambleInclusions;
|
2018-01-19 22:34:02 +08:00
|
|
|
StringRef Contents;
|
|
|
|
Position Pos;
|
|
|
|
IntrusiveRefCntPtr<vfs::FileSystem> VFS;
|
|
|
|
std::shared_ptr<PCHContainerOperations> PCHs;
|
|
|
|
};
|
|
|
|
|
|
|
|
// Invokes Sema code completion on a file.
|
2018-05-15 23:29:32 +08:00
|
|
|
// If \p Includes is set, it will be initialized after a compiler instance has
|
|
|
|
// been set up.
|
[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,
|
|
|
|
std::unique_ptr<IncludeInserter> *Includes = nullptr) {
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
trace::Span Tracer("Sema completion");
|
2017-12-04 21:49:59 +08:00
|
|
|
std::vector<const char *> ArgStrs;
|
2018-01-19 22:34:02 +08:00
|
|
|
for (const auto &S : Input.Command.CommandLine)
|
2017-12-04 21:49:59 +08:00
|
|
|
ArgStrs.push_back(S.c_str());
|
|
|
|
|
2018-02-14 01:15:06 +08:00
|
|
|
if (Input.VFS->setCurrentWorkingDirectory(Input.Command.Directory)) {
|
|
|
|
log("Couldn't set working directory");
|
|
|
|
// We run parsing anyway, our lit-tests rely on results for non-existing
|
|
|
|
// working dirs.
|
|
|
|
}
|
2017-12-04 21:49:59 +08:00
|
|
|
|
|
|
|
IgnoreDiagnostics DummyDiagsConsumer;
|
|
|
|
auto CI = createInvocationFromCommandLine(
|
|
|
|
ArgStrs,
|
|
|
|
CompilerInstance::createDiagnostics(new DiagnosticOptions,
|
|
|
|
&DummyDiagsConsumer, false),
|
2018-01-19 22:34:02 +08:00
|
|
|
Input.VFS);
|
2018-02-09 21:51:57 +08:00
|
|
|
if (!CI) {
|
2018-05-29 19:50:51 +08:00
|
|
|
log("Couldn't create CompilerInvocation");
|
2018-02-09 21:51:57 +08:00
|
|
|
return false;
|
|
|
|
}
|
2018-05-28 20:11:37 +08:00
|
|
|
auto &FrontendOpts = CI->getFrontendOpts();
|
|
|
|
FrontendOpts.DisableFree = false;
|
|
|
|
FrontendOpts.SkipFunctionBodies = true;
|
2018-05-16 20:32:49 +08:00
|
|
|
CI->getLangOpts()->CommentOpts.ParseAllComments = true;
|
2018-01-25 17:44:06 +08:00
|
|
|
// Disable typo correction in Sema.
|
2018-05-28 20:11:37 +08:00
|
|
|
CI->getLangOpts()->SpellChecking = false;
|
|
|
|
// Setup code completion.
|
2017-12-04 21:49:59 +08:00
|
|
|
FrontendOpts.CodeCompleteOpts = Options;
|
2018-01-19 22:34:02 +08:00
|
|
|
FrontendOpts.CodeCompletionAt.FileName = Input.FileName;
|
[clangd] Fix unicode handling, using UTF-16 where LSP requires it.
Summary:
The Language Server Protocol unfortunately mandates that locations in files
be represented by line/column pairs, where the "column" is actually an index
into the UTF-16-encoded text of the line.
(This is because VSCode is written in JavaScript, which is UTF-16-native).
Internally clangd treats source files at UTF-8, the One True Encoding, and
generally deals with byte offsets (though there are exceptions).
Before this patch, conversions between offsets and LSP Position pretended
that Position.character was UTF-8 bytes, which is only true for ASCII lines.
Now we examine the text to convert correctly (but don't actually need to
transcode it, due to some nice details of the encodings).
The updated functions in SourceCode are the blessed way to interact with
the Position.character field, and anything else is likely to be wrong.
So I also updated the other accesses:
- CodeComplete needs a "clang-style" line/column, with column in utf-8 bytes.
This is now converted via Position -> offset -> clang line/column
(a new function is added to SourceCode.h for the second conversion).
- getBeginningOfIdentifier skipped backwards in UTF-16 space, which is will
behave badly when it splits a surrogate pair. Skipping backwards in UTF-8
coordinates gives the lexer a fighting chance of getting this right.
While here, I clarified(?) the logic comments, fixed a bug with identifiers
containing digits, simplified the signature slightly and added a test.
This seems likely to cause problems with editors that have the same bug, and
treat the protocol as if columns are UTF-8 bytes. But we can find and fix those.
Reviewers: hokein
Subscribers: klimek, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D46035
llvm-svn: 331029
2018-04-27 19:59:28 +08:00
|
|
|
auto Offset = positionToOffset(Input.Contents, Input.Pos);
|
|
|
|
if (!Offset) {
|
|
|
|
log("Code completion position was invalid " +
|
|
|
|
llvm::toString(Offset.takeError()));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
std::tie(FrontendOpts.CodeCompletionAt.Line,
|
|
|
|
FrontendOpts.CodeCompletionAt.Column) =
|
|
|
|
offsetToClangLineColumn(Input.Contents, *Offset);
|
2017-12-04 21:49:59 +08:00
|
|
|
|
2018-05-28 20:11:37 +08:00
|
|
|
std::unique_ptr<llvm::MemoryBuffer> ContentsBuffer =
|
|
|
|
llvm::MemoryBuffer::getMemBufferCopy(Input.Contents, Input.FileName);
|
|
|
|
// The diagnostic options must be set before creating a CompilerInstance.
|
|
|
|
CI->getDiagnosticOpts().IgnoreWarnings = true;
|
|
|
|
// We reuse the preamble whether it's valid or not. This is a
|
|
|
|
// correctness/performance tradeoff: building without a preamble is slow, and
|
|
|
|
// completion is latency-sensitive.
|
|
|
|
// NOTE: we must call BeginSourceFile after prepareCompilerInstance. Otherwise
|
|
|
|
// the remapped buffers do not get freed.
|
|
|
|
auto Clang = prepareCompilerInstance(
|
|
|
|
std::move(CI), Input.Preamble, std::move(ContentsBuffer),
|
|
|
|
std::move(Input.PCHs), std::move(Input.VFS), DummyDiagsConsumer);
|
2017-12-04 21:49:59 +08:00
|
|
|
Clang->setCodeCompletionConsumer(Consumer.release());
|
|
|
|
|
|
|
|
SyntaxOnlyAction Action;
|
|
|
|
if (!Action.BeginSourceFile(*Clang, Clang->getFrontendOpts().Inputs[0])) {
|
[clangd] 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
|
|
|
log("BeginSourceFile() failed when running codeComplete for " +
|
|
|
|
Input.FileName);
|
2017-12-04 21:49:59 +08:00
|
|
|
return false;
|
|
|
|
}
|
2018-05-15 23:29:32 +08:00
|
|
|
if (Includes) {
|
|
|
|
// Initialize Includes if provided.
|
|
|
|
|
|
|
|
// FIXME(ioeric): needs more consistent style support in clangd server.
|
|
|
|
auto Style = format::getStyle("file", Input.FileName, "LLVM",
|
|
|
|
Input.Contents, Input.VFS.get());
|
|
|
|
if (!Style) {
|
|
|
|
log("Failed to get FormatStyle for file" + Input.FileName +
|
|
|
|
". Fall back to use LLVM style. Error: " +
|
|
|
|
llvm::toString(Style.takeError()));
|
|
|
|
Style = format::getLLVMStyle();
|
|
|
|
}
|
|
|
|
*Includes = llvm::make_unique<IncludeInserter>(
|
|
|
|
Input.FileName, Input.Contents, *Style, Input.Command.Directory,
|
|
|
|
Clang->getPreprocessor().getHeaderSearchInfo());
|
|
|
|
for (const auto &Inc : Input.PreambleInclusions)
|
|
|
|
Includes->get()->addExisting(Inc);
|
|
|
|
Clang->getPreprocessor().addPPCallbacks(collectInclusionsInMainFileCallback(
|
|
|
|
Clang->getSourceManager(), [Includes](Inclusion Inc) {
|
|
|
|
Includes->get()->addExisting(std::move(Inc));
|
|
|
|
}));
|
|
|
|
}
|
2017-12-04 21:49:59 +08:00
|
|
|
if (!Action.Execute()) {
|
[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
|
|
|
log("Execute() failed when running codeComplete for " + Input.FileName);
|
2017-12-04 21:49:59 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
Action.EndSourceFile();
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2018-05-14 18:50:04 +08:00
|
|
|
// Should we allow index completions in the specified context?
|
|
|
|
bool allowIndex(CodeCompletionContext &CC) {
|
|
|
|
if (!contextAllowsIndex(CC.getKind()))
|
|
|
|
return false;
|
|
|
|
// We also avoid ClassName::bar (but allow namespace::bar).
|
|
|
|
auto Scope = CC.getCXXScopeSpecifier();
|
|
|
|
if (!Scope)
|
|
|
|
return true;
|
|
|
|
NestedNameSpecifier *NameSpec = (*Scope)->getScopeRep();
|
|
|
|
if (!NameSpec)
|
|
|
|
return true;
|
|
|
|
// We only query the index when qualifier is a namespace.
|
|
|
|
// If it's a class, we rely solely on sema completions.
|
|
|
|
switch (NameSpec->getKind()) {
|
|
|
|
case NestedNameSpecifier::Global:
|
|
|
|
case NestedNameSpecifier::Namespace:
|
|
|
|
case NestedNameSpecifier::NamespaceAlias:
|
|
|
|
return true;
|
|
|
|
case NestedNameSpecifier::Super:
|
|
|
|
case NestedNameSpecifier::TypeSpec:
|
|
|
|
case NestedNameSpecifier::TypeSpecWithTemplate:
|
|
|
|
// Unresolved inside a template.
|
|
|
|
case NestedNameSpecifier::Identifier:
|
|
|
|
return false;
|
|
|
|
}
|
2018-05-14 19:47:30 +08:00
|
|
|
llvm_unreachable("invalid NestedNameSpecifier kind");
|
2018-05-14 18:50:04 +08:00
|
|
|
}
|
|
|
|
|
2017-12-04 21:49:59 +08:00
|
|
|
} // namespace
|
|
|
|
|
|
|
|
clang::CodeCompleteOptions CodeCompleteOptions::getClangCompleteOpts() const {
|
|
|
|
clang::CodeCompleteOptions Result;
|
|
|
|
Result.IncludeCodePatterns = EnableSnippets && IncludeCodePatterns;
|
|
|
|
Result.IncludeMacros = IncludeMacros;
|
2018-01-18 23:31:30 +08:00
|
|
|
Result.IncludeGlobals = true;
|
2018-05-16 20:32:44 +08:00
|
|
|
// We choose to include full comments and not do doxygen parsing in
|
|
|
|
// completion.
|
|
|
|
// FIXME: ideally, we should support doxygen in some form, e.g. do markdown
|
|
|
|
// formatting of the comments.
|
|
|
|
Result.IncludeBriefComments = false;
|
2017-12-04 21:49:59 +08:00
|
|
|
|
2018-01-13 02:30:08 +08:00
|
|
|
// When an is used, Sema is responsible for completing the main file,
|
|
|
|
// the index can provide results from the preamble.
|
|
|
|
// Tell Sema not to deserialize the preamble to look for results.
|
|
|
|
Result.LoadExternal = !Index;
|
2017-12-20 00:50:37 +08:00
|
|
|
|
2017-12-04 21:49:59 +08:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
// Runs Sema-based (AST) and Index-based completion, returns merged results.
|
|
|
|
//
|
|
|
|
// There are a few tricky considerations:
|
|
|
|
// - the AST provides information needed for the index query (e.g. which
|
|
|
|
// namespaces to search in). So Sema must start first.
|
|
|
|
// - we only want to return the top results (Opts.Limit).
|
|
|
|
// Building CompletionItems for everything else is wasteful, so we want to
|
|
|
|
// preserve the "native" format until we're done with scoring.
|
|
|
|
// - the data underlying Sema completion items is owned by the AST and various
|
|
|
|
// other arenas, which must stay alive for us to build CompletionItems.
|
|
|
|
// - we may get duplicate results from Sema and the Index, we need to merge.
|
|
|
|
//
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
// So we start Sema completion first, and do all our work in its callback.
|
2018-01-19 22:34:02 +08:00
|
|
|
// We use the Sema context information to query the index.
|
|
|
|
// Then we merge the two result sets, producing items that are Sema/Index/Both.
|
|
|
|
// These items are scored, and the top N are synthesized into the LSP response.
|
|
|
|
// Finally, we can clean up the data structures created by Sema completion.
|
|
|
|
//
|
|
|
|
// Main collaborators are:
|
|
|
|
// - semaCodeComplete sets up the compiler machinery to run code completion.
|
|
|
|
// - CompletionRecorder captures Sema completion results, including context.
|
|
|
|
// - SymbolIndex (Opts.Index) provides index completion results as Symbols
|
|
|
|
// - CompletionCandidates are the result of merging Sema and Index results.
|
|
|
|
// Each candidate points to an underlying CodeCompletionResult (Sema), a
|
|
|
|
// Symbol (Index), or both. It computes the result quality score.
|
|
|
|
// CompletionCandidate also does conversion to CompletionItem (at the end).
|
|
|
|
// - FuzzyMatcher scores how the candidate matches the partial identifier.
|
|
|
|
// This score is combined with the result quality score for the final score.
|
|
|
|
// - TopN determines the results with the best score.
|
|
|
|
class CodeCompleteFlow {
|
2018-02-16 22:15:55 +08:00
|
|
|
PathRef FileName;
|
2018-01-19 22:34:02 +08:00
|
|
|
const CodeCompleteOptions &Opts;
|
|
|
|
// Sema takes ownership of Recorder. Recorder is valid until Sema cleanup.
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
CompletionRecorder *Recorder = nullptr;
|
2018-01-19 22:34:02 +08:00
|
|
|
int NSema = 0, NIndex = 0, NBoth = 0; // Counters for logging.
|
|
|
|
bool Incomplete = false; // Would more be available with a higher limit?
|
2018-05-15 23:29:32 +08:00
|
|
|
llvm::Optional<FuzzyMatcher> Filter; // Initialized once Sema runs.
|
|
|
|
std::unique_ptr<IncludeInserter> Includes; // Initialized once compiler runs.
|
2018-01-19 22:34:02 +08:00
|
|
|
|
|
|
|
public:
|
|
|
|
// A CodeCompleteFlow object is only useful for calling run() exactly once.
|
2018-02-16 22:15:55 +08:00
|
|
|
CodeCompleteFlow(PathRef FileName, const CodeCompleteOptions &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
|
|
|
: FileName(FileName), Opts(Opts) {}
|
2018-01-19 22:34:02 +08:00
|
|
|
|
|
|
|
CompletionList 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");
|
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.
|
|
|
|
CompletionList Output;
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
auto RecorderOwner = llvm::make_unique<CompletionRecorder>(Opts, [&]() {
|
|
|
|
assert(Recorder && "Recorder is not set");
|
2018-05-15 23:29:32 +08:00
|
|
|
assert(Includes && "Includes is not set");
|
|
|
|
// If preprocessor was run, inclusions from preprocessor callback should
|
|
|
|
// already be added to Inclusions.
|
[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-05-15 23:29:32 +08:00
|
|
|
Includes.reset(); // Make sure this doesn't out-live Clang.
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
SPAN_ATTACH(Tracer, "sema_completion_kind",
|
|
|
|
getCompletionKindString(Recorder->CCContext.getKind()));
|
|
|
|
});
|
|
|
|
|
|
|
|
Recorder = RecorderOwner.get();
|
[clangd] Pass Context implicitly using TLS.
Summary:
Instead of passing Context explicitly around, we now have a thread-local
Context object `Context::current()` which is an implicit argument to
every function.
Most manipulation of this should use the WithContextValue helper, which
augments the current Context to add a single KV pair, and restores the
old context on destruction.
Advantages are:
- less boilerplate in functions that just propagate contexts
- reading most code doesn't require understanding context at all, and
using context as values in fewer places still
- fewer options to pass the "wrong" context when it changes within a
scope (e.g. when using Span)
- contexts pass through interfaces we can't modify, such as VFS
- propagating contexts across threads was slightly tricky (e.g.
copy vs move, no move-init in lambdas), and is now encapsulated in
the threadpool
Disadvantages are all the usual TLS stuff - hidden magic, and
potential for higher memory usage on threads that don't use the
context. (In practice, it's just one pointer)
Reviewers: ilya-biryukov
Subscribers: klimek, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D42517
llvm-svn: 323872
2018-01-31 21:40:48 +08:00
|
|
|
semaCodeComplete(std::move(RecorderOwner), Opts.getClangCompleteOpts(),
|
2018-05-15 23:29:32 +08:00
|
|
|
SemaCCInput, &Includes);
|
2018-01-19 22:34:02 +08:00
|
|
|
|
2018-01-31 01:20:54 +08:00
|
|
|
SPAN_ATTACH(Tracer, "sema_results", NSema);
|
|
|
|
SPAN_ATTACH(Tracer, "index_results", NIndex);
|
|
|
|
SPAN_ATTACH(Tracer, "merged_results", NBoth);
|
|
|
|
SPAN_ATTACH(Tracer, "returned_results", Output.items.size());
|
|
|
|
SPAN_ATTACH(Tracer, "incomplete", Output.isIncomplete);
|
[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
|
|
|
log(llvm::formatv("Code complete: {0} results from Sema, {1} from Index, "
|
2018-01-19 22:34:02 +08:00
|
|
|
"{2} matched, {3} returned{4}.",
|
|
|
|
NSema, NIndex, NBoth, Output.items.size(),
|
|
|
|
Output.isIncomplete ? " (incomplete)" : ""));
|
|
|
|
assert(!Opts.Limit || Output.items.size() <= Opts.Limit);
|
|
|
|
// We don't assert that isIncomplete means we hit a limit.
|
|
|
|
// Indexes may choose to impose their own limits even if we don't have one.
|
|
|
|
return Output;
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
// This is called by run() once Sema code completion is done, but before the
|
|
|
|
// Sema data structures are torn down. It does all the real work.
|
|
|
|
CompletionList runWithSema() {
|
|
|
|
Filter = FuzzyMatcher(
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
Recorder->CCSema->getPreprocessor().getCodeCompletionFilter());
|
2018-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.
|
|
|
|
auto IndexResults = queryIndex();
|
|
|
|
// Merge Sema and Index results, score them, and pick the winners.
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
auto Top = mergeResults(Recorder->Results, IndexResults);
|
2018-01-19 22:34:02 +08:00
|
|
|
// Convert the results to the desired LSP structs.
|
|
|
|
CompletionList Output;
|
|
|
|
for (auto &C : Top)
|
|
|
|
Output.items.push_back(toCompletionItem(C.first, C.second));
|
|
|
|
Output.isIncomplete = Incomplete;
|
|
|
|
return Output;
|
|
|
|
}
|
|
|
|
|
|
|
|
SymbolSlab queryIndex() {
|
2018-05-14 18:50:04 +08:00
|
|
|
if (!Opts.Index || !allowIndex(Recorder->CCContext))
|
2018-01-19 22:34:02 +08:00
|
|
|
return SymbolSlab();
|
[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-01-31 01:20:54 +08:00
|
|
|
SPAN_ATTACH(Tracer, "limit", Opts.Limit);
|
|
|
|
|
2018-01-19 22:34:02 +08:00
|
|
|
SymbolSlab::Builder ResultsBuilder;
|
|
|
|
// Build the query.
|
|
|
|
FuzzyFindRequest Req;
|
2018-01-25 17:20:09 +08:00
|
|
|
if (Opts.Limit)
|
|
|
|
Req.MaxCandidateCount = Opts.Limit;
|
2018-01-19 22:34:02 +08:00
|
|
|
Req.Query = Filter->pattern();
|
[clangd] Add "member" symbols to the index
Summary:
This adds more symbols to the index:
- member variables and functions
- enum constants in scoped enums
The code completion behavior should remain intact but workspace symbols should
now provide much more useful symbols.
Other symbols should be considered such as the ones in "main files" (files not
being included) but this can be done separately as this introduces its fair
share of problems.
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewers: ioeric, sammccall
Reviewed By: ioeric, sammccall
Subscribers: hokein, sammccall, jkorous, klimek, ilya-biryukov, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44954
llvm-svn: 334017
2018-06-05 22:01:40 +08:00
|
|
|
Req.RestrictForCodeCompletion = true;
|
[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
|
|
|
Req.Scopes = getQueryScopes(Recorder->CCContext,
|
|
|
|
Recorder->CCSema->getSourceManager());
|
[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
|
|
|
log(llvm::formatv("Code complete: fuzzyFind(\"{0}\", scopes=[{1}])",
|
2018-01-31 01:20:54 +08:00
|
|
|
Req.Query,
|
|
|
|
llvm::join(Req.Scopes.begin(), Req.Scopes.end(), ",")));
|
2018-01-19 22:34:02 +08:00
|
|
|
// Run the query against the index.
|
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();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Merges the Sema and Index results where possible, scores them, and
|
|
|
|
// returns the top results from best to worst.
|
|
|
|
std::vector<std::pair<CompletionCandidate, CompletionItemScores>>
|
|
|
|
mergeResults(const std::vector<CodeCompletionResult> &SemaResults,
|
|
|
|
const SymbolSlab &IndexResults) {
|
[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");
|
2018-01-19 22:34:02 +08:00
|
|
|
// We only keep the best N results at any time, in "native" format.
|
[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
|
|
|
TopN<ScoredCandidate, ScoredCandidateGreater> Top(
|
|
|
|
Opts.Limit == 0 ? std::numeric_limits<size_t>::max() : Opts.Limit);
|
2018-01-19 22:34:02 +08:00
|
|
|
llvm::DenseSet<const Symbol *> UsedIndexResults;
|
|
|
|
auto CorrespondingIndexResult =
|
|
|
|
[&](const CodeCompletionResult &SemaResult) -> const Symbol * {
|
|
|
|
if (auto SymID = getSymbolID(SemaResult)) {
|
|
|
|
auto I = IndexResults.find(*SymID);
|
|
|
|
if (I != IndexResults.end()) {
|
|
|
|
UsedIndexResults.insert(&*I);
|
|
|
|
return &*I;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return nullptr;
|
|
|
|
};
|
|
|
|
// Emit all Sema results, merging them with Index results if possible.
|
[clang] Fix use-after-free on code completion
Summary:
Found by asan. Fiddling with code completion AST after
FrontendAction::Exceute can lead to errors.
Calling the callback in ProcessCodeCompleteResults to make sure we
don't access uninitialized state.
This particular issue comes from the fact that Sema::TUScope is
deleted when destructor of ~Parser runs, but still present in
Sema::TUScope and accessed when building completion items.
I'm still struggling to come up with a small repro. The relevant
stackframes reported by asan are:
ERROR: AddressSanitizer: heap-use-after-free on address
READ of size 8 at 0x61400020d090 thread T175
#0 0x5632dff7821b in llvm::SmallPtrSetImplBase::isSmall() const include/llvm/ADT/SmallPtrSet.h:195:33
#1 0x5632e0335901 in llvm::SmallPtrSetImplBase::insert_imp(void const*) include/llvm/ADT/SmallPtrSet.h:127:9
#2 0x5632e067347d in llvm::SmallPtrSetImpl<clang::Decl*>::insert(clang::Decl*) include/llvm/ADT/SmallPtrSet.h:372:14
#3 0x5632e065df80 in clang::Scope::AddDecl(clang::Decl*) tools/clang/include/clang/Sema/Scope.h:287:18
#4 0x5632e0623eea in clang::ASTReader::pushExternalDeclIntoScope(clang::NamedDecl*, clang::DeclarationName) clang/lib/Serialization/ASTReader.cpp
#5 0x5632e062ce74 in clang::ASTReader::finishPendingActions() tools/clang/lib/Serialization/ASTReader.cpp:9164:9
....
#30 0x5632e02009c4 in clang::index::generateUSRForDecl(clang::Decl const*, llvm::SmallVectorImpl<char>&) tools/clang/lib/Index/USRGeneration.cpp:1037:6
#31 0x5632dff73eab in clang::clangd::(anonymous namespace)::getSymbolID(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:326:20
#32 0x5632dff6fe91 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&)::'lambda'(clang::CodeCompletionResult const&)::operator()(clang::CodeCompletionResult const&) tools/clang/tools/extra/clangd/CodeComplete.cpp:938:24
#33 0x5632dff6e426 in clang::clangd::CodeCompleteFlow::mergeResults(std::vector<clang::CodeCompletionResult, std::allocator<clang::CodeCompletionResult> > const&, clang::clangd::SymbolSlab const&) third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:949:38
#34 0x5632dff7a34d in clang::clangd::CodeCompleteFlow::runWithSema() llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:894:16
#35 0x5632dff6df6a in clang::clangd::CodeCompleteFlow::run(clang::clangd::(anonymous namespace)::SemaCompleteInput const&) &&::'lambda'()::operator()() const third_party/llvm/llvm/tools/clang/tools/extra/clangd/CodeComplete.cpp:858:35
#36 0x5632dff6cd42 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:735:5
0x61400020d090 is located 80 bytes inside of 432-byte region [0x61400020d040,0x61400020d1f0)
freed by thread T175 here:
#0 0x5632df74e115 in operator delete(void*, unsigned long) projects/compiler-rt/lib/asan/asan_new_delete.cc:161:3
#1 0x5632e0b06973 in clang::Parser::~Parser() tools/clang/lib/Parse/Parser.cpp:410:3
#2 0x5632e0b06ddd in clang::Parser::~Parser() clang/lib/Parse/Parser.cpp:408:19
#3 0x5632e0b03286 in std::unique_ptr<clang::Parser, std::default_delete<clang::Parser> >::~unique_ptr() .../bits/unique_ptr.h:236:4
#4 0x5632e0b021c4 in clang::ParseAST(clang::Sema&, bool, bool) tools/clang/lib/Parse/ParseAST.cpp:182:1
#5 0x5632e0726544 in clang::FrontendAction::Execute() tools/clang/lib/Frontend/FrontendAction.cpp:904:8
#6 0x5632dff6cd05 in clang::clangd::(anonymous namespace)::semaCodeComplete(std::unique_ptr<clang::CodeCompleteConsumer, std::default_delete<clang::CodeCompleteConsumer> >, clang::CodeCompleteOptions const&, clang::clangd::(anonymous namespace)::SemaCompleteInput const&, llvm::function_ref<void ()>) tools/clang/tools/extra/clangd/CodeComplete.cpp:728:15
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, jkorous-apple, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D44000
llvm-svn: 326569
2018-03-02 20:28:27 +08:00
|
|
|
for (auto &SemaResult : Recorder->Results)
|
2018-01-19 22:34:02 +08:00
|
|
|
addCandidate(Top, &SemaResult, CorrespondingIndexResult(SemaResult));
|
|
|
|
// Now emit any Index-only results.
|
|
|
|
for (const auto &IndexResult : IndexResults) {
|
|
|
|
if (UsedIndexResults.count(&IndexResult))
|
|
|
|
continue;
|
|
|
|
addCandidate(Top, /*SemaResult=*/nullptr, &IndexResult);
|
|
|
|
}
|
|
|
|
return std::move(Top).items();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Scores a candidate and adds it to the TopN structure.
|
[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
|
|
|
void addCandidate(TopN<ScoredCandidate, ScoredCandidateGreater> &Candidates,
|
|
|
|
const CodeCompletionResult *SemaResult,
|
2018-01-19 22:34:02 +08:00
|
|
|
const Symbol *IndexResult) {
|
|
|
|
CompletionCandidate C;
|
|
|
|
C.SemaResult = SemaResult;
|
|
|
|
C.IndexResult = IndexResult;
|
[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
|
|
|
C.Name = IndexResult ? IndexResult->Name : Recorder->getName(*SemaResult);
|
2018-01-19 22:34:02 +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
|
|
|
SymbolQualitySignals Quality;
|
|
|
|
SymbolRelevanceSignals Relevance;
|
2018-06-06 00:30:25 +08:00
|
|
|
Relevance.Query = SymbolRelevanceSignals::CodeComplete;
|
2018-01-19 22:34:02 +08:00
|
|
|
if (auto FuzzyScore = Filter->match(C.Name))
|
[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-06-06 00:30:25 +08:00
|
|
|
if (IndexResult) {
|
[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
|
|
|
Quality.merge(*IndexResult);
|
2018-06-06 00:30:25 +08:00
|
|
|
Relevance.merge(*IndexResult);
|
|
|
|
}
|
[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
|
|
|
if (SemaResult) {
|
|
|
|
Quality.merge(*SemaResult);
|
|
|
|
Relevance.merge(*SemaResult);
|
|
|
|
}
|
|
|
|
|
|
|
|
float QualScore = Quality.evaluate(), RelScore = Relevance.evaluate();
|
|
|
|
CompletionItemScores Scores;
|
|
|
|
Scores.finalScore = evaluateSymbolAndRelevance(QualScore, RelScore);
|
|
|
|
// The purpose of exporting component scores is to allow NameMatch to be
|
|
|
|
// replaced on the client-side. So we export (NameMatch, final/NameMatch)
|
|
|
|
// rather than (RelScore, QualScore).
|
|
|
|
Scores.filterScore = Relevance.NameMatch;
|
|
|
|
Scores.symbolScore =
|
|
|
|
Scores.filterScore ? Scores.finalScore / Scores.filterScore : QualScore;
|
|
|
|
|
2018-05-23 21:57:48 +08:00
|
|
|
LLVM_DEBUG(llvm::dbgs()
|
|
|
|
<< "CodeComplete: " << C.Name << (IndexResult ? " (index)" : "")
|
|
|
|
<< (SemaResult ? " (sema)" : "") << " = " << Scores.finalScore
|
2018-05-29 19:50:51 +08:00
|
|
|
<< "\n"
|
2018-05-23 21:57:48 +08:00
|
|
|
<< Quality << Relevance << "\n");
|
2018-01-19 22:34:02 +08:00
|
|
|
|
|
|
|
NSema += bool(SemaResult);
|
|
|
|
NIndex += bool(IndexResult);
|
|
|
|
NBoth += SemaResult && IndexResult;
|
2018-02-19 21:04:41 +08:00
|
|
|
if (Candidates.push({C, Scores}))
|
|
|
|
Incomplete = true;
|
2018-01-19 22:34:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
CompletionItem toCompletionItem(const CompletionCandidate &Candidate,
|
|
|
|
const CompletionItemScores &Scores) {
|
|
|
|
CodeCompletionString *SemaCCS = nullptr;
|
2018-05-16 20:32:44 +08:00
|
|
|
std::string DocComment;
|
|
|
|
if (auto *SR = Candidate.SemaResult) {
|
|
|
|
SemaCCS = Recorder->codeCompletionString(*SR);
|
|
|
|
if (Opts.IncludeComments) {
|
|
|
|
assert(Recorder->CCSema);
|
2018-05-24 22:49:23 +08:00
|
|
|
DocComment = getDocComment(Recorder->CCSema->getASTContext(), *SR,
|
|
|
|
/*CommentsFromHeader=*/false);
|
2018-05-16 20:32:44 +08:00
|
|
|
}
|
|
|
|
}
|
2018-05-29 19:50:51 +08:00
|
|
|
return Candidate.build(FileName, Scores, Opts, SemaCCS, Includes.get(),
|
|
|
|
DocComment);
|
2018-01-19 22:34:02 +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
|
|
|
CompletionList codeComplete(PathRef FileName,
|
2017-12-04 21:49:59 +08:00
|
|
|
const tooling::CompileCommand &Command,
|
|
|
|
PrecompiledPreamble const *Preamble,
|
2018-05-15 23:29:32 +08:00
|
|
|
const std::vector<Inclusion> &PreambleInclusions,
|
2017-12-04 21:49:59 +08:00
|
|
|
StringRef Contents, Position Pos,
|
|
|
|
IntrusiveRefCntPtr<vfs::FileSystem> VFS,
|
|
|
|
std::shared_ptr<PCHContainerOperations> PCHs,
|
2017-12-13 20:51:22 +08:00
|
|
|
CodeCompleteOptions Opts) {
|
2018-02-16 22:15:55 +08:00
|
|
|
return CodeCompleteFlow(FileName, Opts)
|
2018-05-15 23:29:32 +08:00
|
|
|
.run({FileName, Command, Preamble, PreambleInclusions, Contents, Pos, VFS,
|
|
|
|
PCHs});
|
2017-12-04 21:49:59 +08:00
|
|
|
}
|
|
|
|
|
[clangd] Pass Context implicitly using TLS.
Summary:
Instead of passing Context explicitly around, we now have a thread-local
Context object `Context::current()` which is an implicit argument to
every function.
Most manipulation of this should use the WithContextValue helper, which
augments the current Context to add a single KV pair, and restores the
old context on destruction.
Advantages are:
- less boilerplate in functions that just propagate contexts
- reading most code doesn't require understanding context at all, and
using context as values in fewer places still
- fewer options to pass the "wrong" context when it changes within a
scope (e.g. when using Span)
- contexts pass through interfaces we can't modify, such as VFS
- propagating contexts across threads was slightly tricky (e.g.
copy vs move, no move-init in lambdas), and is now encapsulated in
the threadpool
Disadvantages are all the usual TLS stuff - hidden magic, and
potential for higher memory usage on threads that don't use the
context. (In practice, it's just one pointer)
Reviewers: ilya-biryukov
Subscribers: klimek, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D42517
llvm-svn: 323872
2018-01-31 21:40:48 +08:00
|
|
|
SignatureHelp signatureHelp(PathRef FileName,
|
2017-12-13 20:51:22 +08:00
|
|
|
const tooling::CompileCommand &Command,
|
|
|
|
PrecompiledPreamble const *Preamble,
|
|
|
|
StringRef Contents, Position Pos,
|
|
|
|
IntrusiveRefCntPtr<vfs::FileSystem> VFS,
|
|
|
|
std::shared_ptr<PCHContainerOperations> PCHs) {
|
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-05-17 04:31:38 +08:00
|
|
|
std::vector<Inclusion> PreambleInclusions = {}; // Unused for signatureHelp
|
[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(llvm::make_unique<SignatureHelpCollector>(Options, Result),
|
|
|
|
Options,
|
2018-05-17 04:31:38 +08:00
|
|
|
{FileName, Command, Preamble, PreambleInclusions, Contents,
|
|
|
|
Pos, std::move(VFS), std::move(PCHs)});
|
2017-12-04 21:49:59 +08:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
[clangd] Add "member" symbols to the index
Summary:
This adds more symbols to the index:
- member variables and functions
- enum constants in scoped enums
The code completion behavior should remain intact but workspace symbols should
now provide much more useful symbols.
Other symbols should be considered such as the ones in "main files" (files not
being included) but this can be done separately as this introduces its fair
share of problems.
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewers: ioeric, sammccall
Reviewed By: ioeric, sammccall
Subscribers: hokein, sammccall, jkorous, klimek, ilya-biryukov, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44954
llvm-svn: 334017
2018-06-05 22:01:40 +08:00
|
|
|
bool isIndexedForCodeCompletion(const NamedDecl &ND, ASTContext &ASTCtx) {
|
|
|
|
using namespace clang::ast_matchers;
|
|
|
|
auto InTopLevelScope = hasDeclContext(
|
|
|
|
anyOf(namespaceDecl(), translationUnitDecl(), linkageSpecDecl()));
|
|
|
|
return !match(decl(anyOf(InTopLevelScope,
|
|
|
|
hasDeclContext(
|
|
|
|
enumDecl(InTopLevelScope, unless(isScoped()))))),
|
|
|
|
ND, ASTCtx)
|
|
|
|
.empty();
|
|
|
|
}
|
|
|
|
|
2017-12-04 21:49:59 +08:00
|
|
|
} // namespace clangd
|
|
|
|
} // namespace clang
|