[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-03-09 22:00:34 +08:00
|
|
|
#include "../AST.h"
|
2018-01-10 01:32:00 +08:00
|
|
|
#include "../CodeCompletionStrings.h"
|
2018-02-07 00:10:35 +08:00
|
|
|
#include "../Logger.h"
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
#include "../SourceCode.h"
|
2018-02-07 00:10:35 +08:00
|
|
|
#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-04-13 19:03:07 +08:00
|
|
|
#include "clang/AST/DeclTemplate.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-04-15 00:27:35 +08:00
|
|
|
/// If \p ND is a template specialization, returns the described template.
|
2018-04-13 19:03:07 +08:00
|
|
|
/// Otherwise, returns \p ND.
|
|
|
|
const NamedDecl &getTemplateOrThis(const NamedDecl &ND) {
|
2018-04-15 00:27:35 +08:00
|
|
|
if (auto T = ND.getDescribedTemplate())
|
|
|
|
return *T;
|
2018-04-13 19:03:07 +08:00
|
|
|
return ND;
|
|
|
|
}
|
|
|
|
|
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-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()));
|
2018-03-09 21:25:29 +08:00
|
|
|
// Don't index template specializations.
|
|
|
|
auto IsSpecialization =
|
|
|
|
anyOf(functionDecl(isExplicitTemplateSpecialization()),
|
|
|
|
cxxRecordDecl(isExplicitTemplateSpecialization()),
|
|
|
|
varDecl(isExplicitTemplateSpecialization()));
|
[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,
|
2018-03-09 21:25:29 +08:00
|
|
|
unless(isScoped())))),
|
|
|
|
unless(IsSpecialization))),
|
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>
|
2018-03-02 02:06:40 +08:00
|
|
|
getIncludeHeader(llvm::StringRef QName, const SourceManager &SM,
|
|
|
|
SourceLocation Loc, const SymbolCollector::Options &Opts) {
|
2018-02-16 22:15:55 +08:00
|
|
|
llvm::StringRef FilePath = SM.getFilename(Loc);
|
|
|
|
if (FilePath.empty())
|
|
|
|
return llvm::None;
|
|
|
|
if (Opts.Includes) {
|
2018-03-02 02:06:40 +08:00
|
|
|
llvm::StringRef Mapped = Opts.Includes->mapHeader(FilePath, QName);
|
2018-02-16 22:15:55 +08:00
|
|
|
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-03-09 22:00:34 +08:00
|
|
|
SourceLocation NameLoc = findNameLoc(&D);
|
|
|
|
auto U = toURI(SM, SM.getFilename(NameLoc), 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-04-13 16:30:39 +08:00
|
|
|
auto TokenLength = clang::Lexer::MeasureTokenLength(NameLoc, SM, LangOpts);
|
|
|
|
|
|
|
|
auto CreatePosition = [&SM](SourceLocation Loc) {
|
2018-04-30 19:40:02 +08:00
|
|
|
auto LSPLoc = sourceLocToPosition(SM, Loc);
|
2018-04-13 16:30:39 +08:00
|
|
|
SymbolLocation::Position Pos;
|
2018-04-30 19:40:02 +08:00
|
|
|
Pos.Line = LSPLoc.line;
|
|
|
|
Pos.Column = LSPLoc.character;
|
2018-04-13 16:30:39 +08:00
|
|
|
return Pos;
|
|
|
|
};
|
|
|
|
|
|
|
|
Result.Start = CreatePosition(NameLoc);
|
|
|
|
auto EndLoc = NameLoc.getLocWithOffset(TokenLength);
|
|
|
|
Result.End = CreatePosition(EndLoc);
|
|
|
|
|
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
|
2018-03-30 04:03:16 +08:00
|
|
|
// the first seen declaration as canonical declaration is not a good enough
|
[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
|
|
|
// 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,
|
2018-04-09 22:28:52 +08:00
|
|
|
ArrayRef<index::SymbolRelation> Relations, SourceLocation Loc,
|
[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
|
|
|
index::IndexDataConsumer::ASTNodeInfo ASTNode) {
|
2018-01-10 22:57:58 +08:00
|
|
|
assert(ASTCtx && PP.get() && "ASTContext and Preprocessor must be set.");
|
2018-03-12 22:49:09 +08:00
|
|
|
assert(CompletionAllocator && CompletionTUInfo);
|
|
|
|
const NamedDecl *ND = llvm::dyn_cast<NamedDecl>(D);
|
|
|
|
if (!ND)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// Mark D as referenced if this is a reference coming from the main file.
|
|
|
|
// D may not be an interesting symbol, but it's cheaper to check at the end.
|
2018-04-09 22:28:52 +08:00
|
|
|
auto &SM = ASTCtx->getSourceManager();
|
2018-03-12 22:49:09 +08:00
|
|
|
if (Opts.CountReferences &&
|
|
|
|
(Roles & static_cast<unsigned>(index::SymbolRole::Reference)) &&
|
2018-04-09 22:28:52 +08:00
|
|
|
SM.getFileID(SM.getSpellingLoc(Loc)) == SM.getMainFileID())
|
2018-03-12 22:49:09 +08:00
|
|
|
ReferencedDecls.insert(ND);
|
2018-01-10 22:57:58 +08:00
|
|
|
|
2018-03-12 22:49:09 +08:00
|
|
|
// Don't continue indexing if this is a mere reference.
|
[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 (!(Roles & static_cast<unsigned>(index::SymbolRole::Declaration) ||
|
|
|
|
Roles & static_cast<unsigned>(index::SymbolRole::Definition)))
|
|
|
|
return true;
|
2018-03-12 22:49:09 +08:00
|
|
|
if (shouldFilterDecl(ND, ASTCtx, Opts))
|
|
|
|
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-03-12 22:49:09 +08:00
|
|
|
llvm::SmallString<128> USR;
|
|
|
|
if (index::generateUSRForDecl(ND, USR))
|
|
|
|
return true;
|
|
|
|
SymbolID ID(USR);
|
2018-01-10 01:32:00 +08:00
|
|
|
|
2018-03-12 22:49:09 +08:00
|
|
|
const NamedDecl &OriginalDecl = *cast<NamedDecl>(ASTNode.OrigD);
|
|
|
|
const Symbol *BasicSymbol = Symbols.find(ID);
|
|
|
|
if (!BasicSymbol) // Regardless of role, ND is the canonical declaration.
|
|
|
|
BasicSymbol = addDeclaration(*ND, std::move(ID));
|
|
|
|
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));
|
[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-03-12 22:49:09 +08:00
|
|
|
if (Roles & static_cast<unsigned>(index::SymbolRole::Definition))
|
|
|
|
addDefinition(OriginalDecl, *BasicSymbol);
|
|
|
|
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
|
|
|
|
2018-03-12 22:49:09 +08:00
|
|
|
void SymbolCollector::finish() {
|
|
|
|
// At the end of the TU, add 1 to the refcount of the ReferencedDecls.
|
|
|
|
for (const auto *ND : ReferencedDecls) {
|
|
|
|
llvm::SmallString<128> USR;
|
|
|
|
if (!index::generateUSRForDecl(ND, USR))
|
|
|
|
if (const auto *S = Symbols.find(SymbolID(USR))) {
|
|
|
|
Symbol Inc = *S;
|
|
|
|
++Inc.References;
|
|
|
|
Symbols.insert(Inc);
|
|
|
|
}
|
2018-02-09 22:42:01 +08:00
|
|
|
}
|
2018-03-12 22:49:09 +08:00
|
|
|
ReferencedDecls.clear();
|
2018-02-09 22:42:01 +08:00
|
|
|
}
|
[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();
|
[clangd] Implementation of workspace/symbol request
Summary:
This is a basic implementation of the "workspace/symbol" request which is
used to find symbols by a string query. Since this is similar to code completion
in terms of result, this implementation reuses the "fuzzyFind" in order to get
matches. For now, the scoring algorithm is the same as code completion and
improvements could be done in the future.
The index model doesn't contain quite enough symbols for this to cover
common symbols like methods, enum class enumerators, functions in unamed
namespaces, etc. The index model will be augmented separately to achieve this.
Reviewers: sammccall, ilya-biryukov
Reviewed By: sammccall
Subscribers: jkorous, hokein, simark, sammccall, klimek, mgorny, ilya-biryukov, mgrang, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44882
llvm-svn: 330637
2018-04-24 04:00:52 +08:00
|
|
|
assert(!StringRef(QName).startswith("::"));
|
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.");
|
2018-04-13 19:03:07 +08:00
|
|
|
// We use the primary template, as clang does during code completion.
|
|
|
|
CodeCompletionResult SymbolCompletion(&getTemplateOrThis(ND), 0);
|
2018-02-09 22:42:01 +08:00
|
|
|
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.
|
2018-03-02 02:06:40 +08:00
|
|
|
if (auto Header = getIncludeHeader(
|
|
|
|
QName, SM, SM.getExpansionLoc(ND.getLocation()), Opts))
|
2018-02-16 22:15:55 +08:00
|
|
|
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
|