2018-08-15 00:03:32 +08:00
|
|
|
//===--- Index.h -------------------------------------------------*- C++-*-===//
|
[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
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
[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-08-15 00:03:32 +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
|
|
|
|
|
|
|
#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_INDEX_INDEX_H
|
|
|
|
#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_INDEX_INDEX_H
|
|
|
|
|
2019-02-28 21:49:25 +08:00
|
|
|
#include "Ref.h"
|
2019-06-03 12:55:46 +08:00
|
|
|
#include "Relation.h"
|
2019-02-28 21:23:03 +08:00
|
|
|
#include "Symbol.h"
|
2018-11-28 00:40:34 +08:00
|
|
|
#include "SymbolID.h"
|
2017-12-24 03:38:03 +08:00
|
|
|
#include "llvm/ADT/DenseSet.h"
|
2018-01-10 01:32:00 +08:00
|
|
|
#include "llvm/ADT/Optional.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/ADT/StringExtras.h"
|
2018-09-10 19:51:05 +08:00
|
|
|
#include "llvm/Support/JSON.h"
|
[clangd] Factor out the data-swapping functionality from MemIndex/DexIndex.
Summary:
This is now handled by a wrapper class SwapIndex, so MemIndex/DexIndex can be
immutable and focus on their job.
Old and busted:
I have a MemIndex, which holds a shared_ptr<vector<Symbol*>>, which keeps the
symbol slab alive. I update by calling build(shared_ptr<vector<Symbol*>>).
New hotness: I have a SwapIndex, which holds a unique_ptr<SymbolIndex>, which
holds a MemIndex, which holds a shared_ptr<void>, which keeps backing
data alive.
I update by building a new MemIndex and calling SwapIndex::reset().
Reviewers: kbobyrev, ioeric
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, mgrang, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51422
llvm-svn: 341318
2018-09-03 22:37:43 +08:00
|
|
|
#include <mutex>
|
[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 <string>
|
|
|
|
|
|
|
|
namespace clang {
|
|
|
|
namespace clangd {
|
|
|
|
|
2017-12-14 19:25:49 +08:00
|
|
|
struct FuzzyFindRequest {
|
|
|
|
/// \brief A query string for the fuzzy find. This is matched against symbols'
|
2017-12-19 19:37:40 +08:00
|
|
|
/// un-qualified identifiers and should not contain qualifiers like "::".
|
2017-12-14 19:25:49 +08:00
|
|
|
std::string Query;
|
2017-12-19 19:37:40 +08:00
|
|
|
/// \brief If this is non-empty, symbols must be in at least one of the scopes
|
2018-01-20 06:18:21 +08:00
|
|
|
/// (e.g. namespaces) excluding nested scopes. For example, if a scope "xyz::"
|
|
|
|
/// is provided, the matched symbols must be defined in namespace xyz but not
|
|
|
|
/// namespace xyz::abc.
|
2017-12-19 19:37:40 +08:00
|
|
|
///
|
2018-01-20 06:18:21 +08:00
|
|
|
/// The global scope is "", a top level scope is "foo::", etc.
|
2017-12-19 19:37:40 +08:00
|
|
|
std::vector<std::string> Scopes;
|
2018-09-28 02:46:00 +08:00
|
|
|
/// If set to true, allow symbols from any scope. Scopes explicitly listed
|
|
|
|
/// above will be ranked higher.
|
|
|
|
bool AnyScope = false;
|
2018-01-15 20:33:00 +08:00
|
|
|
/// \brief The number of top candidates to return. The index may choose to
|
|
|
|
/// return more than this, e.g. if it doesn't know which candidates are best.
|
2018-09-13 22:27:03 +08:00
|
|
|
llvm::Optional<uint32_t> Limit;
|
[clangd] Add "member" symbols to the index
Summary:
This adds more symbols to the index:
- member variables and functions
- enum constants in scoped enums
The code completion behavior should remain intact but workspace symbols should
now provide much more useful symbols.
Other symbols should be considered such as the ones in "main files" (files not
being included) but this can be done separately as this introduces its fair
share of problems.
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewers: ioeric, sammccall
Reviewed By: ioeric, sammccall
Subscribers: hokein, sammccall, jkorous, klimek, ilya-biryukov, jkorous-apple, ioeric, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D44954
llvm-svn: 334017
2018-06-05 22:01:40 +08:00
|
|
|
/// If set to true, only symbols for completion support will be considered.
|
|
|
|
bool RestrictForCodeCompletion = false;
|
2018-06-12 16:48:20 +08:00
|
|
|
/// Contextually relevant files (e.g. the file we're code-completing in).
|
|
|
|
/// Paths should be absolute.
|
|
|
|
std::vector<std::string> ProximityPaths;
|
2019-02-06 23:36:23 +08:00
|
|
|
/// Preferred types of symbols. These are raw representation of `OpaqueType`.
|
|
|
|
std::vector<std::string> PreferredTypes;
|
2018-11-26 23:38:01 +08:00
|
|
|
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
bool operator==(const FuzzyFindRequest &Req) const {
|
2018-09-13 22:27:03 +08:00
|
|
|
return std::tie(Query, Scopes, Limit, RestrictForCodeCompletion,
|
2019-02-06 23:36:23 +08:00
|
|
|
ProximityPaths, PreferredTypes) ==
|
2018-09-13 22:27:03 +08:00
|
|
|
std::tie(Req.Query, Req.Scopes, Req.Limit,
|
2019-02-06 23:36:23 +08:00
|
|
|
Req.RestrictForCodeCompletion, Req.ProximityPaths,
|
|
|
|
Req.PreferredTypes);
|
[clangd] Speculative code completion index request before Sema is run.
Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.
Trace with speculative index request:{F6997544}
Reviewers: hokein, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D50962
llvm-svn: 340604
2018-08-24 19:23:56 +08:00
|
|
|
}
|
|
|
|
bool operator!=(const FuzzyFindRequest &Req) const { return !(*this == Req); }
|
2017-12-14 19:25:49 +08:00
|
|
|
};
|
2018-09-10 19:51:05 +08:00
|
|
|
bool fromJSON(const llvm::json::Value &Value, FuzzyFindRequest &Request);
|
|
|
|
llvm::json::Value toJSON(const FuzzyFindRequest &Request);
|
2017-12-14 19:25:49 +08:00
|
|
|
|
2018-03-14 17:48:05 +08:00
|
|
|
struct LookupRequest {
|
|
|
|
llvm::DenseSet<SymbolID> IDs;
|
|
|
|
};
|
|
|
|
|
[clangd] SymbolOccurrences -> Refs and cleanup
Summary:
A few things that I noticed while merging the SwapIndex patch:
- SymbolOccurrences and particularly SymbolOccurrenceSlab are unwieldy names,
and these names appear *a lot*. Ref, RefSlab, etc seem clear enough
and read/format much better.
- The asymmetry between SymbolSlab and RefSlab (build() vs freeze()) is
confusing and irritating, and doesn't even save much code.
Avoiding RefSlab::Builder was my idea, but it was a bad one; add it.
- DenseMap<SymbolID, ArrayRef<Ref>> seems like a reasonable compromise for
constructing MemIndex - and means many less wasted allocations than the
current DenseMap<SymbolID, vector<Ref*>> for FileIndex, and none for
slabs.
- RefSlab::find() is not actually used for anything, so we can throw
away the DenseMap and keep the representation much more compact.
- A few naming/consistency fixes: e.g. Slabs,Refs -> Symbols,Refs.
Reviewers: ioeric
Subscribers: ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51605
llvm-svn: 341368
2018-09-04 22:39:56 +08:00
|
|
|
struct RefsRequest {
|
2018-08-06 21:14:32 +08:00
|
|
|
llvm::DenseSet<SymbolID> IDs;
|
[clangd] SymbolOccurrences -> Refs and cleanup
Summary:
A few things that I noticed while merging the SwapIndex patch:
- SymbolOccurrences and particularly SymbolOccurrenceSlab are unwieldy names,
and these names appear *a lot*. Ref, RefSlab, etc seem clear enough
and read/format much better.
- The asymmetry between SymbolSlab and RefSlab (build() vs freeze()) is
confusing and irritating, and doesn't even save much code.
Avoiding RefSlab::Builder was my idea, but it was a bad one; add it.
- DenseMap<SymbolID, ArrayRef<Ref>> seems like a reasonable compromise for
constructing MemIndex - and means many less wasted allocations than the
current DenseMap<SymbolID, vector<Ref*>> for FileIndex, and none for
slabs.
- RefSlab::find() is not actually used for anything, so we can throw
away the DenseMap and keep the representation much more compact.
- A few naming/consistency fixes: e.g. Slabs,Refs -> Symbols,Refs.
Reviewers: ioeric
Subscribers: ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51605
llvm-svn: 341368
2018-09-04 22:39:56 +08:00
|
|
|
RefKind Filter = RefKind::All;
|
2019-01-15 02:11:09 +08:00
|
|
|
/// If set, limit the number of refers returned from the index. The index may
|
|
|
|
/// choose to return less than this, e.g. it tries to avoid returning stale
|
|
|
|
/// results.
|
|
|
|
llvm::Optional<uint32_t> Limit;
|
2018-08-06 21:14:32 +08:00
|
|
|
};
|
|
|
|
|
2019-06-15 10:26:47 +08:00
|
|
|
struct RelationsRequest {
|
|
|
|
llvm::DenseSet<SymbolID> Subjects;
|
|
|
|
index::SymbolRole Predicate;
|
|
|
|
/// If set, limit the number of relations returned from the index.
|
|
|
|
llvm::Optional<uint32_t> Limit;
|
|
|
|
};
|
|
|
|
|
[clangd] Factor out the data-swapping functionality from MemIndex/DexIndex.
Summary:
This is now handled by a wrapper class SwapIndex, so MemIndex/DexIndex can be
immutable and focus on their job.
Old and busted:
I have a MemIndex, which holds a shared_ptr<vector<Symbol*>>, which keeps the
symbol slab alive. I update by calling build(shared_ptr<vector<Symbol*>>).
New hotness: I have a SwapIndex, which holds a unique_ptr<SymbolIndex>, which
holds a MemIndex, which holds a shared_ptr<void>, which keeps backing
data alive.
I update by building a new MemIndex and calling SwapIndex::reset().
Reviewers: kbobyrev, ioeric
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, mgrang, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51422
llvm-svn: 341318
2018-09-03 22:37:43 +08:00
|
|
|
/// Interface for symbol indexes that can be used for searching or
|
2017-12-14 19:25:49 +08:00
|
|
|
/// matching symbols among a set of symbols based on names or unique IDs.
|
|
|
|
class SymbolIndex {
|
|
|
|
public:
|
|
|
|
virtual ~SymbolIndex() = default;
|
|
|
|
|
|
|
|
/// \brief Matches symbols in the index fuzzily and applies \p Callback on
|
|
|
|
/// each matched symbol before returning.
|
2018-01-15 20:33:00 +08:00
|
|
|
/// If returned Symbols are used outside Callback, they must be deep-copied!
|
2017-12-14 19:25:49 +08:00
|
|
|
///
|
2018-09-13 22:27:03 +08:00
|
|
|
/// Returns true if there may be more results (limited by Req.Limit).
|
2017-12-14 19:25:49 +08:00
|
|
|
virtual bool
|
[clangd] Pass Context implicitly using TLS.
Summary:
Instead of passing Context explicitly around, we now have a thread-local
Context object `Context::current()` which is an implicit argument to
every function.
Most manipulation of this should use the WithContextValue helper, which
augments the current Context to add a single KV pair, and restores the
old context on destruction.
Advantages are:
- less boilerplate in functions that just propagate contexts
- reading most code doesn't require understanding context at all, and
using context as values in fewer places still
- fewer options to pass the "wrong" context when it changes within a
scope (e.g. when using Span)
- contexts pass through interfaces we can't modify, such as VFS
- propagating contexts across threads was slightly tricky (e.g.
copy vs move, no move-init in lambdas), and is now encapsulated in
the threadpool
Disadvantages are all the usual TLS stuff - hidden magic, and
potential for higher memory usage on threads that don't use the
context. (In practice, it's just one pointer)
Reviewers: ilya-biryukov
Subscribers: klimek, jkorous-apple, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D42517
llvm-svn: 323872
2018-01-31 21:40:48 +08:00
|
|
|
fuzzyFind(const FuzzyFindRequest &Req,
|
2017-12-28 22:47:01 +08:00
|
|
|
llvm::function_ref<void(const Symbol &)> Callback) const = 0;
|
2017-12-14 19:25:49 +08:00
|
|
|
|
2018-03-14 17:48:05 +08:00
|
|
|
/// Looks up symbols with any of the given symbol IDs and applies \p Callback
|
|
|
|
/// on each matched symbol.
|
|
|
|
/// The returned symbol must be deep-copied if it's used outside Callback.
|
|
|
|
virtual void
|
|
|
|
lookup(const LookupRequest &Req,
|
|
|
|
llvm::function_ref<void(const Symbol &)> Callback) const = 0;
|
|
|
|
|
[clangd] SymbolOccurrences -> Refs and cleanup
Summary:
A few things that I noticed while merging the SwapIndex patch:
- SymbolOccurrences and particularly SymbolOccurrenceSlab are unwieldy names,
and these names appear *a lot*. Ref, RefSlab, etc seem clear enough
and read/format much better.
- The asymmetry between SymbolSlab and RefSlab (build() vs freeze()) is
confusing and irritating, and doesn't even save much code.
Avoiding RefSlab::Builder was my idea, but it was a bad one; add it.
- DenseMap<SymbolID, ArrayRef<Ref>> seems like a reasonable compromise for
constructing MemIndex - and means many less wasted allocations than the
current DenseMap<SymbolID, vector<Ref*>> for FileIndex, and none for
slabs.
- RefSlab::find() is not actually used for anything, so we can throw
away the DenseMap and keep the representation much more compact.
- A few naming/consistency fixes: e.g. Slabs,Refs -> Symbols,Refs.
Reviewers: ioeric
Subscribers: ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51605
llvm-svn: 341368
2018-09-04 22:39:56 +08:00
|
|
|
/// Finds all occurrences (e.g. references, declarations, definitions) of a
|
|
|
|
/// symbol and applies \p Callback on each result.
|
2018-08-06 21:14:32 +08:00
|
|
|
///
|
[clangd] SymbolOccurrences -> Refs and cleanup
Summary:
A few things that I noticed while merging the SwapIndex patch:
- SymbolOccurrences and particularly SymbolOccurrenceSlab are unwieldy names,
and these names appear *a lot*. Ref, RefSlab, etc seem clear enough
and read/format much better.
- The asymmetry between SymbolSlab and RefSlab (build() vs freeze()) is
confusing and irritating, and doesn't even save much code.
Avoiding RefSlab::Builder was my idea, but it was a bad one; add it.
- DenseMap<SymbolID, ArrayRef<Ref>> seems like a reasonable compromise for
constructing MemIndex - and means many less wasted allocations than the
current DenseMap<SymbolID, vector<Ref*>> for FileIndex, and none for
slabs.
- RefSlab::find() is not actually used for anything, so we can throw
away the DenseMap and keep the representation much more compact.
- A few naming/consistency fixes: e.g. Slabs,Refs -> Symbols,Refs.
Reviewers: ioeric
Subscribers: ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51605
llvm-svn: 341368
2018-09-04 22:39:56 +08:00
|
|
|
/// Results should be returned in arbitrary order.
|
2018-08-06 21:14:32 +08:00
|
|
|
/// The returned result must be deep-copied if it's used outside Callback.
|
[clangd] SymbolOccurrences -> Refs and cleanup
Summary:
A few things that I noticed while merging the SwapIndex patch:
- SymbolOccurrences and particularly SymbolOccurrenceSlab are unwieldy names,
and these names appear *a lot*. Ref, RefSlab, etc seem clear enough
and read/format much better.
- The asymmetry between SymbolSlab and RefSlab (build() vs freeze()) is
confusing and irritating, and doesn't even save much code.
Avoiding RefSlab::Builder was my idea, but it was a bad one; add it.
- DenseMap<SymbolID, ArrayRef<Ref>> seems like a reasonable compromise for
constructing MemIndex - and means many less wasted allocations than the
current DenseMap<SymbolID, vector<Ref*>> for FileIndex, and none for
slabs.
- RefSlab::find() is not actually used for anything, so we can throw
away the DenseMap and keep the representation much more compact.
- A few naming/consistency fixes: e.g. Slabs,Refs -> Symbols,Refs.
Reviewers: ioeric
Subscribers: ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51605
llvm-svn: 341368
2018-09-04 22:39:56 +08:00
|
|
|
virtual void refs(const RefsRequest &Req,
|
|
|
|
llvm::function_ref<void(const Ref &)> Callback) const = 0;
|
2018-08-24 17:12:54 +08:00
|
|
|
|
2019-06-15 10:26:47 +08:00
|
|
|
/// Finds all relations (S, P, O) stored in the index such that S is among
|
|
|
|
/// Req.Subjects and P is Req.Predicate, and invokes \p Callback for (S, O) in
|
|
|
|
/// each.
|
|
|
|
virtual void relations(
|
|
|
|
const RelationsRequest &Req,
|
|
|
|
llvm::function_ref<void(const SymbolID &Subject, const Symbol &Object)>
|
|
|
|
Callback) const = 0;
|
|
|
|
|
2018-08-24 17:12:54 +08:00
|
|
|
/// Returns estimated size of index (in bytes).
|
|
|
|
virtual size_t estimateMemoryUsage() const = 0;
|
2017-12-14 19:25:49 +08:00
|
|
|
};
|
|
|
|
|
[clangd] Factor out the data-swapping functionality from MemIndex/DexIndex.
Summary:
This is now handled by a wrapper class SwapIndex, so MemIndex/DexIndex can be
immutable and focus on their job.
Old and busted:
I have a MemIndex, which holds a shared_ptr<vector<Symbol*>>, which keeps the
symbol slab alive. I update by calling build(shared_ptr<vector<Symbol*>>).
New hotness: I have a SwapIndex, which holds a unique_ptr<SymbolIndex>, which
holds a MemIndex, which holds a shared_ptr<void>, which keeps backing
data alive.
I update by building a new MemIndex and calling SwapIndex::reset().
Reviewers: kbobyrev, ioeric
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, mgrang, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51422
llvm-svn: 341318
2018-09-03 22:37:43 +08:00
|
|
|
// Delegating implementation of SymbolIndex whose delegate can be swapped out.
|
|
|
|
class SwapIndex : public SymbolIndex {
|
|
|
|
public:
|
|
|
|
// If an index is not provided, reset() must be called.
|
|
|
|
SwapIndex(std::unique_ptr<SymbolIndex> Index = nullptr)
|
|
|
|
: Index(std::move(Index)) {}
|
|
|
|
void reset(std::unique_ptr<SymbolIndex>);
|
|
|
|
|
|
|
|
// SymbolIndex methods delegate to the current index, which is kept alive
|
|
|
|
// until the call returns (even if reset() is called).
|
|
|
|
bool fuzzyFind(const FuzzyFindRequest &,
|
|
|
|
llvm::function_ref<void(const Symbol &)>) const override;
|
|
|
|
void lookup(const LookupRequest &,
|
|
|
|
llvm::function_ref<void(const Symbol &)>) const override;
|
[clangd] SymbolOccurrences -> Refs and cleanup
Summary:
A few things that I noticed while merging the SwapIndex patch:
- SymbolOccurrences and particularly SymbolOccurrenceSlab are unwieldy names,
and these names appear *a lot*. Ref, RefSlab, etc seem clear enough
and read/format much better.
- The asymmetry between SymbolSlab and RefSlab (build() vs freeze()) is
confusing and irritating, and doesn't even save much code.
Avoiding RefSlab::Builder was my idea, but it was a bad one; add it.
- DenseMap<SymbolID, ArrayRef<Ref>> seems like a reasonable compromise for
constructing MemIndex - and means many less wasted allocations than the
current DenseMap<SymbolID, vector<Ref*>> for FileIndex, and none for
slabs.
- RefSlab::find() is not actually used for anything, so we can throw
away the DenseMap and keep the representation much more compact.
- A few naming/consistency fixes: e.g. Slabs,Refs -> Symbols,Refs.
Reviewers: ioeric
Subscribers: ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51605
llvm-svn: 341368
2018-09-04 22:39:56 +08:00
|
|
|
void refs(const RefsRequest &,
|
|
|
|
llvm::function_ref<void(const Ref &)>) const override;
|
2019-06-15 10:26:47 +08:00
|
|
|
void relations(const RelationsRequest &,
|
|
|
|
llvm::function_ref<void(const SymbolID &, const Symbol &)>)
|
|
|
|
const override;
|
|
|
|
|
[clangd] Factor out the data-swapping functionality from MemIndex/DexIndex.
Summary:
This is now handled by a wrapper class SwapIndex, so MemIndex/DexIndex can be
immutable and focus on their job.
Old and busted:
I have a MemIndex, which holds a shared_ptr<vector<Symbol*>>, which keeps the
symbol slab alive. I update by calling build(shared_ptr<vector<Symbol*>>).
New hotness: I have a SwapIndex, which holds a unique_ptr<SymbolIndex>, which
holds a MemIndex, which holds a shared_ptr<void>, which keeps backing
data alive.
I update by building a new MemIndex and calling SwapIndex::reset().
Reviewers: kbobyrev, ioeric
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, mgrang, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51422
llvm-svn: 341318
2018-09-03 22:37:43 +08:00
|
|
|
size_t estimateMemoryUsage() const override;
|
|
|
|
|
|
|
|
private:
|
|
|
|
std::shared_ptr<SymbolIndex> snapshot() const;
|
|
|
|
mutable std::mutex Mutex;
|
|
|
|
std::shared_ptr<SymbolIndex> Index;
|
|
|
|
};
|
|
|
|
|
[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
|
2018-08-15 00:03:32 +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
|
|
|
#endif // LLVM_CLANG_TOOLS_EXTRA_CLANGD_INDEX_INDEX_H
|