[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
//===--- SymbolCollector.cpp -------------------------------------*- C++-*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "SymbolCollector.h"
|
2018-01-10 01:32:00 +08:00
|
|
|
#include "../CodeCompletionStrings.h"
|
2018-02-07 00:10:35 +08:00
|
|
|
#include "../Logger.h"
|
|
|
|
#include "../URI.h"
|
2018-02-16 22:15:55 +08:00
|
|
|
#include "CanonicalIncludes.h"
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
#include "clang/AST/DeclCXX.h"
|
2018-01-10 22:57:58 +08:00
|
|
|
#include "clang/ASTMatchers/ASTMatchFinder.h"
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
#include "clang/Basic/SourceManager.h"
|
|
|
|
#include "clang/Index/IndexSymbol.h"
|
|
|
|
#include "clang/Index/USRGeneration.h"
|
2018-01-29 23:13:29 +08:00
|
|
|
#include "llvm/Support/FileSystem.h"
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
#include "llvm/Support/MemoryBuffer.h"
|
|
|
|
#include "llvm/Support/Path.h"
|
|
|
|
|
|
|
|
namespace clang {
|
|
|
|
namespace clangd {
|
|
|
|
|
|
|
|
namespace {
|
2018-02-07 00:10:35 +08:00
|
|
|
// Returns a URI of \p Path. Firstly, this makes the \p Path absolute using the
|
|
|
|
// current working directory of the given SourceManager if the Path is not an
|
|
|
|
// absolute path. If failed, this resolves relative paths against \p FallbackDir
|
|
|
|
// to get an absolute path. Then, this tries creating an URI for the absolute
|
|
|
|
// path with schemes specified in \p Opts. This returns an URI with the first
|
|
|
|
// working scheme, if there is any; otherwise, this returns None.
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
//
|
|
|
|
// The Path can be a path relative to the build directory, or retrieved from
|
|
|
|
// the SourceManager.
|
2018-02-07 00:10:35 +08:00
|
|
|
llvm::Optional<std::string> toURI(const SourceManager &SM, StringRef Path,
|
|
|
|
const SymbolCollector::Options &Opts) {
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
llvm::SmallString<128> AbsolutePath(Path);
|
|
|
|
if (std::error_code EC =
|
|
|
|
SM.getFileManager().getVirtualFileSystem()->makeAbsolute(
|
|
|
|
AbsolutePath))
|
|
|
|
llvm::errs() << "Warning: could not make absolute file: '" << EC.message()
|
|
|
|
<< '\n';
|
2018-01-29 23:13:29 +08:00
|
|
|
if (llvm::sys::path::is_absolute(AbsolutePath)) {
|
|
|
|
// Handle the symbolic link path case where the current working directory
|
|
|
|
// (getCurrentWorkingDirectory) is a symlink./ We always want to the real
|
|
|
|
// file path (instead of the symlink path) for the C++ symbols.
|
|
|
|
//
|
|
|
|
// Consider the following example:
|
|
|
|
//
|
|
|
|
// src dir: /project/src/foo.h
|
|
|
|
// current working directory (symlink): /tmp/build -> /project/src/
|
|
|
|
//
|
|
|
|
// The file path of Symbol is "/project/src/foo.h" instead of
|
|
|
|
// "/tmp/build/foo.h"
|
|
|
|
if (const DirectoryEntry *Dir = SM.getFileManager().getDirectory(
|
|
|
|
llvm::sys::path::parent_path(AbsolutePath.str()))) {
|
|
|
|
StringRef DirName = SM.getFileManager().getCanonicalName(Dir);
|
|
|
|
SmallString<128> AbsoluteFilename;
|
|
|
|
llvm::sys::path::append(AbsoluteFilename, DirName,
|
|
|
|
llvm::sys::path::filename(AbsolutePath.str()));
|
|
|
|
AbsolutePath = AbsoluteFilename;
|
|
|
|
}
|
2018-02-07 00:10:35 +08:00
|
|
|
} else if (!Opts.FallbackDir.empty()) {
|
|
|
|
llvm::sys::fs::make_absolute(Opts.FallbackDir, AbsolutePath);
|
2018-01-29 23:13:29 +08:00
|
|
|
llvm::sys::path::remove_dots(AbsolutePath, /*remove_dot_dot=*/true);
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
}
|
2018-02-07 00:10:35 +08:00
|
|
|
|
|
|
|
std::string ErrMsg;
|
|
|
|
for (const auto &Scheme : Opts.URISchemes) {
|
|
|
|
auto U = URI::create(AbsolutePath, Scheme);
|
|
|
|
if (U)
|
|
|
|
return U->toString();
|
|
|
|
ErrMsg += llvm::toString(U.takeError()) + "\n";
|
|
|
|
}
|
|
|
|
log(llvm::Twine("Failed to create an URI for file ") + AbsolutePath + ": " +
|
|
|
|
ErrMsg);
|
|
|
|
return llvm::None;
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
}
|
2017-12-19 19:37:40 +08:00
|
|
|
|
2018-01-20 06:18:21 +08:00
|
|
|
// "a::b::c", return {"a::b::", "c"}. Scope is empty if there's no qualifier.
|
2017-12-19 19:37:40 +08:00
|
|
|
std::pair<llvm::StringRef, llvm::StringRef>
|
|
|
|
splitQualifiedName(llvm::StringRef QName) {
|
|
|
|
assert(!QName.startswith("::") && "Qualified names should not start with ::");
|
|
|
|
size_t Pos = QName.rfind("::");
|
|
|
|
if (Pos == llvm::StringRef::npos)
|
|
|
|
return {StringRef(), QName};
|
2018-01-20 06:18:21 +08:00
|
|
|
return {QName.substr(0, Pos + 2), QName.substr(Pos + 2)};
|
2017-12-19 19:37:40 +08:00
|
|
|
}
|
|
|
|
|
2018-01-10 22:57:58 +08:00
|
|
|
bool shouldFilterDecl(const NamedDecl *ND, ASTContext *ASTCtx,
|
|
|
|
const SymbolCollector::Options &Opts) {
|
|
|
|
using namespace clang::ast_matchers;
|
|
|
|
if (ND->isImplicit())
|
|
|
|
return true;
|
2018-01-19 17:35:55 +08:00
|
|
|
// Skip anonymous declarations, e.g (anonymous enum/class/struct).
|
|
|
|
if (ND->getDeclName().isEmpty())
|
|
|
|
return true;
|
|
|
|
|
2018-01-10 22:57:58 +08:00
|
|
|
// FIXME: figure out a way to handle internal linkage symbols (e.g. static
|
|
|
|
// variables, function) defined in the .cc files. Also we skip the symbols
|
|
|
|
// in anonymous namespace as the qualifier names of these symbols are like
|
|
|
|
// `foo::<anonymous>::bar`, which need a special handling.
|
|
|
|
// In real world projects, we have a relatively large set of header files
|
|
|
|
// that define static variables (like "static const int A = 1;"), we still
|
|
|
|
// want to collect these symbols, although they cause potential ODR
|
|
|
|
// violations.
|
|
|
|
if (ND->isInAnonymousNamespace())
|
|
|
|
return true;
|
|
|
|
|
2018-01-19 17:35:55 +08:00
|
|
|
// We only want:
|
|
|
|
// * symbols in namespaces or translation unit scopes (e.g. no class
|
|
|
|
// members)
|
|
|
|
// * enum constants in unscoped enum decl (e.g. "red" in "enum {red};")
|
2018-02-02 18:31:42 +08:00
|
|
|
auto InTopLevelScope = hasDeclContext(
|
|
|
|
anyOf(namespaceDecl(), translationUnitDecl(), linkageSpecDecl()));
|
[clangd] Prefer the definition of a TagDecl (e.g. class) as CanonicalDeclaration.
Summary:
Currently, we pick the first declaration of a symbol in a TU, which is considered
canonical in the clangIndex, as the canonical declaration in clangd. This causes
forward declarations that might appear in a random header to be used as a
canonical declaration, which is not desirable for features like go-to-declaration
or include insertion.
For example, for class X, we would consider the forward declaration in fwd.h to
be the canonical declaration, while the preferred canonical declaration should
be the actual definition in x.h.
```
// fwd.h
class X; // forward decl
// x.h
class X {};
```
This patch fixes the issue by making symbol collector favor the actual definition of
a TagDecl (i.e. class/struct/enum/union) found in a header file over the first seen
declarations in a TU. Other symbol types like functions are not handled because
using the first seen declarations as canonical declarations is usually a good
heuristic for them.
Reviewers: sammccall
Subscribers: klimek, ilya-biryukov, jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D43823
llvm-svn: 326313
2018-02-28 17:33:15 +08:00
|
|
|
if (match(decl(allOf(unless(isExpansionInMainFile()),
|
2018-01-19 17:35:55 +08:00
|
|
|
anyOf(InTopLevelScope,
|
|
|
|
hasDeclContext(enumDecl(InTopLevelScope,
|
|
|
|
unless(isScoped())))))),
|
2018-01-10 22:57:58 +08:00
|
|
|
*ND, *ASTCtx)
|
|
|
|
.empty())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-02-16 22:15:55 +08:00
|
|
|
// We only collect #include paths for symbols that are suitable for global code
|
|
|
|
// completion, except for namespaces since #include path for a namespace is hard
|
|
|
|
// to define.
|
|
|
|
bool shouldCollectIncludePath(index::SymbolKind Kind) {
|
|
|
|
using SK = index::SymbolKind;
|
|
|
|
switch (Kind) {
|
|
|
|
case SK::Macro:
|
|
|
|
case SK::Enum:
|
|
|
|
case SK::Struct:
|
|
|
|
case SK::Class:
|
|
|
|
case SK::Union:
|
|
|
|
case SK::TypeAlias:
|
|
|
|
case SK::Using:
|
|
|
|
case SK::Function:
|
|
|
|
case SK::Variable:
|
|
|
|
case SK::EnumConstant:
|
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[clangd] Not collect include headers for dynamic index for now.
Summary:
The new behaviors introduced by this patch:
o When include collection is enabled, we always set IncludeHeader field in Symbol
even if it's the same as FileURI in decl.
o Disable include collection in FileIndex which is currently only used to build
dynamic index. We should revisit when we actually want to use FileIndex to global
index.
o Code-completion only uses IncludeHeader to insert headers but not FileURI in
CanonicalDeclaration. This ensures that inserted headers are always canonicalized.
Note that include insertion can still be triggered for symbols that are already
included if they are merged from dynamic index and static index, but we would
only use includes that are already canonicalized (e.g. from static index).
Reason for change:
Collecting header includes in dynamic index enables inserting includes for headers
that are not indexed but opened in the editor. Comparing to inserting includes for
symbols in global/static index, this is nice-to-have but would probably require
non-trivial amount of work to get right. For example:
o Currently it's not easy to fully support CanonicalIncludes in dynamic index, given the way
we run dynamic index.
o It's also harder to reason about the correctness of include canonicalization for dynamic index
(i.e. symbols in the current file/TU) than static index where symbols are collected
offline and sanity check is possible before shipping to production.
o We have less control/flexibility over symbol info in the dynamic index
(e.g. URIs, path normalization), which could be used to help make decision when inserting includes.
As header collection (especially canonicalization) is relatively new, and enabling
it for dynamic index would immediately affect current users with only dynamic
index support, I propose we disable it for dynamic index for now to avoid
compromising other hot features like code completion and only support it for
static index where include insertion would likely to bring more value.
Reviewers: ilya-biryukov, sammccall, hokein
Subscribers: klimek, jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D43550
llvm-svn: 325764
2018-02-22 18:14:05 +08:00
|
|
|
/// Gets a canonical include (URI of the header or <header> or "header") for
|
|
|
|
/// header of \p Loc.
|
|
|
|
/// Returns None if fails to get include header for \p Loc.
|
2018-02-16 22:15:55 +08:00
|
|
|
/// FIXME: we should handle .inc files whose symbols are expected be exported by
|
|
|
|
/// their containing headers.
|
|
|
|
llvm::Optional<std::string>
|
|
|
|
getIncludeHeader(const SourceManager &SM, SourceLocation Loc,
|
|
|
|
const SymbolCollector::Options &Opts) {
|
|
|
|
llvm::StringRef FilePath = SM.getFilename(Loc);
|
|
|
|
if (FilePath.empty())
|
|
|
|
return llvm::None;
|
|
|
|
if (Opts.Includes) {
|
|
|
|
llvm::StringRef Mapped = Opts.Includes->mapHeader(FilePath);
|
|
|
|
if (Mapped != FilePath)
|
|
|
|
return (Mapped.startswith("<") || Mapped.startswith("\""))
|
|
|
|
? Mapped.str()
|
|
|
|
: ("\"" + Mapped + "\"").str();
|
|
|
|
}
|
[clangd] Not collect include headers for dynamic index for now.
Summary:
The new behaviors introduced by this patch:
o When include collection is enabled, we always set IncludeHeader field in Symbol
even if it's the same as FileURI in decl.
o Disable include collection in FileIndex which is currently only used to build
dynamic index. We should revisit when we actually want to use FileIndex to global
index.
o Code-completion only uses IncludeHeader to insert headers but not FileURI in
CanonicalDeclaration. This ensures that inserted headers are always canonicalized.
Note that include insertion can still be triggered for symbols that are already
included if they are merged from dynamic index and static index, but we would
only use includes that are already canonicalized (e.g. from static index).
Reason for change:
Collecting header includes in dynamic index enables inserting includes for headers
that are not indexed but opened in the editor. Comparing to inserting includes for
symbols in global/static index, this is nice-to-have but would probably require
non-trivial amount of work to get right. For example:
o Currently it's not easy to fully support CanonicalIncludes in dynamic index, given the way
we run dynamic index.
o It's also harder to reason about the correctness of include canonicalization for dynamic index
(i.e. symbols in the current file/TU) than static index where symbols are collected
offline and sanity check is possible before shipping to production.
o We have less control/flexibility over symbol info in the dynamic index
(e.g. URIs, path normalization), which could be used to help make decision when inserting includes.
As header collection (especially canonicalization) is relatively new, and enabling
it for dynamic index would immediately affect current users with only dynamic
index support, I propose we disable it for dynamic index for now to avoid
compromising other hot features like code completion and only support it for
static index where include insertion would likely to bring more value.
Reviewers: ilya-biryukov, sammccall, hokein
Subscribers: klimek, jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D43550
llvm-svn: 325764
2018-02-22 18:14:05 +08:00
|
|
|
|
|
|
|
return toURI(SM, SM.getFilename(Loc), Opts);
|
2018-02-16 22:15:55 +08:00
|
|
|
}
|
|
|
|
|
2018-01-31 20:56:51 +08:00
|
|
|
// Return the symbol location of the given declaration `D`.
|
|
|
|
//
|
|
|
|
// For symbols defined inside macros:
|
|
|
|
// * use expansion location, if the symbol is formed via macro concatenation.
|
|
|
|
// * use spelling location, otherwise.
|
[clangd] Prefer the definition of a TagDecl (e.g. class) as CanonicalDeclaration.
Summary:
Currently, we pick the first declaration of a symbol in a TU, which is considered
canonical in the clangIndex, as the canonical declaration in clangd. This causes
forward declarations that might appear in a random header to be used as a
canonical declaration, which is not desirable for features like go-to-declaration
or include insertion.
For example, for class X, we would consider the forward declaration in fwd.h to
be the canonical declaration, while the preferred canonical declaration should
be the actual definition in x.h.
```
// fwd.h
class X; // forward decl
// x.h
class X {};
```
This patch fixes the issue by making symbol collector favor the actual definition of
a TagDecl (i.e. class/struct/enum/union) found in a header file over the first seen
declarations in a TU. Other symbol types like functions are not handled because
using the first seen declarations as canonical declarations is usually a good
heuristic for them.
Reviewers: sammccall
Subscribers: klimek, ilya-biryukov, jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D43823
llvm-svn: 326313
2018-02-28 17:33:15 +08:00
|
|
|
llvm::Optional<SymbolLocation> getSymbolLocation(
|
|
|
|
const NamedDecl &D, SourceManager &SM, const SymbolCollector::Options &Opts,
|
|
|
|
const clang::LangOptions &LangOpts, std::string &FileURIStorage) {
|
2018-02-13 17:53:50 +08:00
|
|
|
SourceLocation SpellingLoc = SM.getSpellingLoc(D.getLocation());
|
|
|
|
if (D.getLocation().isMacroID()) {
|
|
|
|
std::string PrintLoc = SpellingLoc.printToString(SM);
|
2018-02-06 17:50:35 +08:00
|
|
|
if (llvm::StringRef(PrintLoc).startswith("<scratch") ||
|
|
|
|
llvm::StringRef(PrintLoc).startswith("<command line>")) {
|
2018-02-07 00:10:35 +08:00
|
|
|
// We use the expansion location for the following symbols, as spelling
|
|
|
|
// locations of these symbols are not interesting to us:
|
|
|
|
// * symbols formed via macro concatenation, the spelling location will
|
|
|
|
// be "<scratch space>"
|
|
|
|
// * symbols controlled and defined by a compile command-line option
|
|
|
|
// `-DName=foo`, the spelling location will be "<command line>".
|
2018-02-13 17:53:50 +08:00
|
|
|
SpellingLoc = SM.getExpansionRange(D.getLocation()).first;
|
2018-01-31 20:56:51 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-02-13 17:53:50 +08:00
|
|
|
auto U = toURI(SM, SM.getFilename(SpellingLoc), Opts);
|
2018-02-07 00:10:35 +08:00
|
|
|
if (!U)
|
|
|
|
return llvm::None;
|
|
|
|
FileURIStorage = std::move(*U);
|
2018-02-09 22:42:01 +08:00
|
|
|
SymbolLocation Result;
|
|
|
|
Result.FileURI = FileURIStorage;
|
2018-02-13 17:53:50 +08:00
|
|
|
Result.StartOffset = SM.getFileOffset(SpellingLoc);
|
|
|
|
Result.EndOffset = Result.StartOffset + clang::Lexer::MeasureTokenLength(
|
|
|
|
SpellingLoc, SM, LangOpts);
|
2018-02-09 22:42:01 +08:00
|
|
|
return std::move(Result);
|
2018-01-31 20:56:51 +08:00
|
|
|
}
|
|
|
|
|
[clangd] Prefer the definition of a TagDecl (e.g. class) as CanonicalDeclaration.
Summary:
Currently, we pick the first declaration of a symbol in a TU, which is considered
canonical in the clangIndex, as the canonical declaration in clangd. This causes
forward declarations that might appear in a random header to be used as a
canonical declaration, which is not desirable for features like go-to-declaration
or include insertion.
For example, for class X, we would consider the forward declaration in fwd.h to
be the canonical declaration, while the preferred canonical declaration should
be the actual definition in x.h.
```
// fwd.h
class X; // forward decl
// x.h
class X {};
```
This patch fixes the issue by making symbol collector favor the actual definition of
a TagDecl (i.e. class/struct/enum/union) found in a header file over the first seen
declarations in a TU. Other symbol types like functions are not handled because
using the first seen declarations as canonical declarations is usually a good
heuristic for them.
Reviewers: sammccall
Subscribers: klimek, ilya-biryukov, jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D43823
llvm-svn: 326313
2018-02-28 17:33:15 +08:00
|
|
|
// Checks whether \p ND is a definition of a TagDecl (class/struct/enum/union)
|
|
|
|
// in a header file, in which case clangd would prefer to use ND as a canonical
|
|
|
|
// declaration.
|
|
|
|
// FIXME: handle symbol types that are not TagDecl (e.g. functions), if using
|
|
|
|
// the the first seen declaration as canonical declaration is not a good enough
|
|
|
|
// heuristic.
|
|
|
|
bool isPreferredDeclaration(const NamedDecl &ND, index::SymbolRoleSet Roles) {
|
|
|
|
using namespace clang::ast_matchers;
|
|
|
|
return (Roles & static_cast<unsigned>(index::SymbolRole::Definition)) &&
|
|
|
|
llvm::isa<TagDecl>(&ND) &&
|
|
|
|
match(decl(isExpansionInMainFile()), ND, ND.getASTContext()).empty();
|
|
|
|
}
|
|
|
|
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
} // namespace
|
|
|
|
|
2018-01-10 22:57:58 +08:00
|
|
|
SymbolCollector::SymbolCollector(Options Opts) : Opts(std::move(Opts)) {}
|
|
|
|
|
2018-01-10 01:32:00 +08:00
|
|
|
void SymbolCollector::initialize(ASTContext &Ctx) {
|
|
|
|
ASTCtx = &Ctx;
|
|
|
|
CompletionAllocator = std::make_shared<GlobalCodeCompletionAllocator>();
|
|
|
|
CompletionTUInfo =
|
|
|
|
llvm::make_unique<CodeCompletionTUInfo>(CompletionAllocator);
|
|
|
|
}
|
|
|
|
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
// Always return true to continue indexing.
|
|
|
|
bool SymbolCollector::handleDeclOccurence(
|
|
|
|
const Decl *D, index::SymbolRoleSet Roles,
|
|
|
|
ArrayRef<index::SymbolRelation> Relations, FileID FID, unsigned Offset,
|
|
|
|
index::IndexDataConsumer::ASTNodeInfo ASTNode) {
|
2018-01-10 22:57:58 +08:00
|
|
|
assert(ASTCtx && PP.get() && "ASTContext and Preprocessor must be set.");
|
|
|
|
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
// FIXME: collect all symbol references.
|
|
|
|
if (!(Roles & static_cast<unsigned>(index::SymbolRole::Declaration) ||
|
|
|
|
Roles & static_cast<unsigned>(index::SymbolRole::Definition)))
|
|
|
|
return true;
|
|
|
|
|
2018-01-10 01:32:00 +08:00
|
|
|
assert(CompletionAllocator && CompletionTUInfo);
|
|
|
|
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
if (const NamedDecl *ND = llvm::dyn_cast<NamedDecl>(D)) {
|
2018-01-10 22:57:58 +08:00
|
|
|
if (shouldFilterDecl(ND, ASTCtx, Opts))
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
return true;
|
2017-12-28 22:47:01 +08:00
|
|
|
llvm::SmallString<128> USR;
|
|
|
|
if (index::generateUSRForDecl(ND, USR))
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
return true;
|
|
|
|
|
[clangd] Prefer the definition of a TagDecl (e.g. class) as CanonicalDeclaration.
Summary:
Currently, we pick the first declaration of a symbol in a TU, which is considered
canonical in the clangIndex, as the canonical declaration in clangd. This causes
forward declarations that might appear in a random header to be used as a
canonical declaration, which is not desirable for features like go-to-declaration
or include insertion.
For example, for class X, we would consider the forward declaration in fwd.h to
be the canonical declaration, while the preferred canonical declaration should
be the actual definition in x.h.
```
// fwd.h
class X; // forward decl
// x.h
class X {};
```
This patch fixes the issue by making symbol collector favor the actual definition of
a TagDecl (i.e. class/struct/enum/union) found in a header file over the first seen
declarations in a TU. Other symbol types like functions are not handled because
using the first seen declarations as canonical declarations is usually a good
heuristic for them.
Reviewers: sammccall
Subscribers: klimek, ilya-biryukov, jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D43823
llvm-svn: 326313
2018-02-28 17:33:15 +08:00
|
|
|
const NamedDecl &OriginalDecl = *cast<NamedDecl>(ASTNode.OrigD);
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
auto ID = SymbolID(USR);
|
[clangd] Prefer the definition of a TagDecl (e.g. class) as CanonicalDeclaration.
Summary:
Currently, we pick the first declaration of a symbol in a TU, which is considered
canonical in the clangIndex, as the canonical declaration in clangd. This causes
forward declarations that might appear in a random header to be used as a
canonical declaration, which is not desirable for features like go-to-declaration
or include insertion.
For example, for class X, we would consider the forward declaration in fwd.h to
be the canonical declaration, while the preferred canonical declaration should
be the actual definition in x.h.
```
// fwd.h
class X; // forward decl
// x.h
class X {};
```
This patch fixes the issue by making symbol collector favor the actual definition of
a TagDecl (i.e. class/struct/enum/union) found in a header file over the first seen
declarations in a TU. Other symbol types like functions are not handled because
using the first seen declarations as canonical declarations is usually a good
heuristic for them.
Reviewers: sammccall
Subscribers: klimek, ilya-biryukov, jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D43823
llvm-svn: 326313
2018-02-28 17:33:15 +08:00
|
|
|
const Symbol *BasicSymbol = Symbols.find(ID);
|
2018-02-09 22:42:01 +08:00
|
|
|
if (!BasicSymbol) // Regardless of role, ND is the canonical declaration.
|
|
|
|
BasicSymbol = addDeclaration(*ND, std::move(ID));
|
[clangd] Prefer the definition of a TagDecl (e.g. class) as CanonicalDeclaration.
Summary:
Currently, we pick the first declaration of a symbol in a TU, which is considered
canonical in the clangIndex, as the canonical declaration in clangd. This causes
forward declarations that might appear in a random header to be used as a
canonical declaration, which is not desirable for features like go-to-declaration
or include insertion.
For example, for class X, we would consider the forward declaration in fwd.h to
be the canonical declaration, while the preferred canonical declaration should
be the actual definition in x.h.
```
// fwd.h
class X; // forward decl
// x.h
class X {};
```
This patch fixes the issue by making symbol collector favor the actual definition of
a TagDecl (i.e. class/struct/enum/union) found in a header file over the first seen
declarations in a TU. Other symbol types like functions are not handled because
using the first seen declarations as canonical declarations is usually a good
heuristic for them.
Reviewers: sammccall
Subscribers: klimek, ilya-biryukov, jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D43823
llvm-svn: 326313
2018-02-28 17:33:15 +08:00
|
|
|
else if (isPreferredDeclaration(OriginalDecl, Roles))
|
|
|
|
// If OriginalDecl is preferred, replace the existing canonical
|
|
|
|
// declaration (e.g. a class forward declaration). There should be at most
|
|
|
|
// one duplicate as we expect to see only one preferred declaration per
|
|
|
|
// TU, because in practice they are definitions.
|
|
|
|
BasicSymbol = addDeclaration(OriginalDecl, std::move(ID));
|
|
|
|
|
2018-02-09 22:42:01 +08:00
|
|
|
if (Roles & static_cast<unsigned>(index::SymbolRole::Definition))
|
[clangd] Prefer the definition of a TagDecl (e.g. class) as CanonicalDeclaration.
Summary:
Currently, we pick the first declaration of a symbol in a TU, which is considered
canonical in the clangIndex, as the canonical declaration in clangd. This causes
forward declarations that might appear in a random header to be used as a
canonical declaration, which is not desirable for features like go-to-declaration
or include insertion.
For example, for class X, we would consider the forward declaration in fwd.h to
be the canonical declaration, while the preferred canonical declaration should
be the actual definition in x.h.
```
// fwd.h
class X; // forward decl
// x.h
class X {};
```
This patch fixes the issue by making symbol collector favor the actual definition of
a TagDecl (i.e. class/struct/enum/union) found in a header file over the first seen
declarations in a TU. Other symbol types like functions are not handled because
using the first seen declarations as canonical declarations is usually a good
heuristic for them.
Reviewers: sammccall
Subscribers: klimek, ilya-biryukov, jkorous-apple, cfe-commits
Differential Revision: https://reviews.llvm.org/D43823
llvm-svn: 326313
2018-02-28 17:33:15 +08:00
|
|
|
addDefinition(OriginalDecl, *BasicSymbol);
|
2018-02-09 22:42:01 +08:00
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
|
2018-02-09 22:42:01 +08:00
|
|
|
const Symbol *SymbolCollector::addDeclaration(const NamedDecl &ND,
|
|
|
|
SymbolID ID) {
|
|
|
|
auto &SM = ND.getASTContext().getSourceManager();
|
2018-02-02 18:31:42 +08:00
|
|
|
|
2018-02-09 22:42:01 +08:00
|
|
|
std::string QName;
|
|
|
|
llvm::raw_string_ostream OS(QName);
|
|
|
|
PrintingPolicy Policy(ASTCtx->getLangOpts());
|
|
|
|
// Note that inline namespaces are treated as transparent scopes. This
|
|
|
|
// reflects the way they're most commonly used for lookup. Ideally we'd
|
|
|
|
// include them, but at query time it's hard to find all the inline
|
|
|
|
// namespaces to query: the preamble doesn't have a dedicated list.
|
|
|
|
Policy.SuppressUnwrittenScope = true;
|
|
|
|
ND.printQualifiedName(OS, Policy);
|
|
|
|
OS.flush();
|
2017-12-22 16:12:39 +08:00
|
|
|
|
2018-02-09 22:42:01 +08:00
|
|
|
Symbol S;
|
|
|
|
S.ID = std::move(ID);
|
|
|
|
std::tie(S.Scope, S.Name) = splitQualifiedName(QName);
|
|
|
|
S.SymInfo = index::getSymbolInfo(&ND);
|
|
|
|
std::string FileURI;
|
2018-02-13 17:53:50 +08:00
|
|
|
if (auto DeclLoc =
|
|
|
|
getSymbolLocation(ND, SM, Opts, ASTCtx->getLangOpts(), FileURI))
|
2018-02-09 22:42:01 +08:00
|
|
|
S.CanonicalDeclaration = *DeclLoc;
|
2018-01-10 01:32:00 +08:00
|
|
|
|
2018-02-09 22:42:01 +08:00
|
|
|
// Add completion info.
|
|
|
|
// FIXME: we may want to choose a different redecl, or combine from several.
|
|
|
|
assert(ASTCtx && PP.get() && "ASTContext and Preprocessor must be set.");
|
|
|
|
CodeCompletionResult SymbolCompletion(&ND, 0);
|
|
|
|
const auto *CCS = SymbolCompletion.CreateCodeCompletionString(
|
|
|
|
*ASTCtx, *PP, CodeCompletionContext::CCC_Name, *CompletionAllocator,
|
|
|
|
*CompletionTUInfo,
|
|
|
|
/*IncludeBriefComments*/ true);
|
|
|
|
std::string Label;
|
|
|
|
std::string SnippetInsertText;
|
|
|
|
std::string IgnoredLabel;
|
|
|
|
std::string PlainInsertText;
|
|
|
|
getLabelAndInsertText(*CCS, &Label, &SnippetInsertText,
|
|
|
|
/*EnableSnippets=*/true);
|
|
|
|
getLabelAndInsertText(*CCS, &IgnoredLabel, &PlainInsertText,
|
|
|
|
/*EnableSnippets=*/false);
|
|
|
|
std::string FilterText = getFilterText(*CCS);
|
|
|
|
std::string Documentation = getDocumentation(*CCS);
|
|
|
|
std::string CompletionDetail = getDetail(*CCS);
|
2018-01-10 01:32:00 +08:00
|
|
|
|
2018-02-16 22:15:55 +08:00
|
|
|
std::string Include;
|
|
|
|
if (Opts.CollectIncludePath && shouldCollectIncludePath(S.SymInfo.Kind)) {
|
|
|
|
// Use the expansion location to get the #include header since this is
|
|
|
|
// where the symbol is exposed.
|
|
|
|
if (auto Header =
|
|
|
|
getIncludeHeader(SM, SM.getExpansionLoc(ND.getLocation()), Opts))
|
|
|
|
Include = std::move(*Header);
|
|
|
|
}
|
2018-02-09 22:42:01 +08:00
|
|
|
S.CompletionFilterText = FilterText;
|
|
|
|
S.CompletionLabel = Label;
|
|
|
|
S.CompletionPlainInsertText = PlainInsertText;
|
|
|
|
S.CompletionSnippetInsertText = SnippetInsertText;
|
|
|
|
Symbol::Details Detail;
|
|
|
|
Detail.Documentation = Documentation;
|
|
|
|
Detail.CompletionDetail = CompletionDetail;
|
2018-02-16 22:15:55 +08:00
|
|
|
Detail.IncludeHeader = Include;
|
2018-02-09 22:42:01 +08:00
|
|
|
S.Detail = &Detail;
|
2018-01-10 01:32:00 +08:00
|
|
|
|
2018-02-09 22:42:01 +08:00
|
|
|
Symbols.insert(S);
|
|
|
|
return Symbols.find(S.ID);
|
|
|
|
}
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
|
2018-02-09 22:42:01 +08:00
|
|
|
void SymbolCollector::addDefinition(const NamedDecl &ND,
|
|
|
|
const Symbol &DeclSym) {
|
|
|
|
if (DeclSym.Definition)
|
|
|
|
return;
|
|
|
|
// If we saw some forward declaration, we end up copying the symbol.
|
|
|
|
// This is not ideal, but avoids duplicating the "is this a definition" check
|
|
|
|
// in clang::index. We should only see one definition.
|
|
|
|
Symbol S = DeclSym;
|
|
|
|
std::string FileURI;
|
|
|
|
if (auto DefLoc = getSymbolLocation(ND, ND.getASTContext().getSourceManager(),
|
2018-02-13 17:53:50 +08:00
|
|
|
Opts, ASTCtx->getLangOpts(), FileURI))
|
2018-02-09 22:42:01 +08:00
|
|
|
S.Definition = *DefLoc;
|
|
|
|
Symbols.insert(S);
|
[clangd] Introduce a "Symbol" class.
Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
information of a C++ symbol needed by clangd. clangd will use it in clangd's
AST/dynamic index and global/static index (code completion and code
navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
symbols when the source file is changed (for ASTIndex), or to generate
all C++ symbols for the whole project.
In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.
Reviewers: ioeric, sammccall, ilya-biryukov, malaperle
Reviewed By: sammccall
Subscribers: malaperle, klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D40897
llvm-svn: 320486
2017-12-12 23:42:10 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace clangd
|
|
|
|
} // namespace clang
|