Some operations such as code completion produce a set of candidates. More...

Namespaces
namespace	vfs
namespace	yaml

Classes
struct	DenseMapInfo< clang::clangd::Config::ExternalIndexSpec >
struct	DenseMapInfo< clang::clangd::dex::Token >
struct	DenseMapInfo< clang::clangd::dex::Trigram >
struct	DenseMapInfo< clang::clangd::IncludeStructure::HeaderID >
struct	DenseMapInfo< clang::clangd::Range >
struct	DenseMapInfo< clang::clangd::RefSlab::Builder::Entry >
struct	DenseMapInfo< clang::clangd::SymbolID >
struct	DenseMapInfo< clang::tidy::cppcoreguidelines::SpecialMemberFunctionsCheck::ClassDefId >
	Specialization of DenseMapInfo to allow ClassDefId objects in DenseMaps FIXME: Move this to the corresponding cpp file as is done for clang-tidy/readability/IdentifierNamingCheck.cpp. More...
struct	DenseMapInfo< clang::tidy::RenamerClangTidyCheck::NamingCheckId >
	Specialization of DenseMapInfo to allow NamingCheckId objects in DenseMaps. More...
struct	DenseMapInfo< DriverArgs >
struct	format_provider< clang::clangd::Position >
struct	GraphTraits< const VarUseGraph * >
struct	GraphTraits< const VarUseNode * >
class	SmallVectorImpl

Typedefs
using	DriverArgs = clang::clangd::DriverArgs

Functions
template<typename T>
static bool	operator== (const llvm::simple_ilist< T > &LHS, const llvm::simple_ilist< T > &RHS)
template<typename T>
static bool	operator!= (const llvm::simple_ilist< T > &LHS, const llvm::simple_ilist< T > &RHS)
int	get_physical_cores ()
raw_ostream &	operator<< (raw_ostream &OS, const clang::clangd::FeatureModuleRegistry::entry &E)
raw_ostream &	operator<< (raw_ostream &OS, const iterator_range< Registry< clang::clangd::FeatureModule >::iterator > &Rng)
raw_ostream &	operator<< (raw_ostream &OS, const clang::clangd::Tweak &T)

Detailed Description

Some operations such as code completion produce a set of candidates.

Usually the user can choose between them, but we should put the best options at the top (they're easier to select, and more likely to be seen).

This file defines building blocks for ranking candidates. It's used by the features directly and also in the implementation of indexes, as indexes also need to heuristically limit their results.

The facilities here are:

retrieving scoring signals from e.g. indexes, AST, CodeCompletionString These are structured in a way that they can be debugged, and are fairly consistent regardless of the source.
compute scores from scoring signals. These are suitable for sorting.
sorting utilities like the TopN container. These could be split up further to isolate dependencies if we care.

Typedef Documentation

◆ DriverArgs

using llvm::DriverArgs = clang::clangd::DriverArgs

Definition at line 218 of file SystemIncludeExtractor.cpp.

Function Documentation

◆ get_physical_cores()

int llvm::get_physical_cores ( )

◆ operator!=()

template<typename T>

bool llvm::operator!=	(	const llvm::simple_ilist< T > &	LHS,
		const llvm::simple_ilist< T > &	RHS )

static

Definition at line 48 of file YAMLGenerator.cpp.

◆ operator<<() [1/3]

raw_ostream & llvm::operator<<	(	raw_ostream &	OS,
		const clang::clangd::FeatureModuleRegistry::entry &	E )

Definition at line 19 of file FeatureModulesRegistryTests.cpp.

◆ operator<<() [2/3]

raw_ostream & llvm::operator<<	(	raw_ostream &	OS,
		const clang::clangd::Tweak &	T )

Definition at line 42 of file FeatureModulesRegistryTests.cpp.

◆ operator<<() [3/3]

raw_ostream & llvm::operator<<	(	raw_ostream &	OS,
		const iterator_range< Registry< clang::clangd::FeatureModule >::iterator > &	Rng )

Definition at line 25 of file FeatureModulesRegistryTests.cpp.

◆ operator==()