2018-08-15 00:03:32 +08:00
|
|
|
//===--- CodeComplete.h ------------------------------------------*- C++-*-===//
|
2017-12-04 21:49:59 +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
|
2017-12-04 21:49:59 +08:00
|
|
|
//
|
2018-08-15 00:03:32 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2017-12-04 21:49:59 +08:00
|
|
|
//
|
|
|
|
// Code completion provides suggestions for what the user might type next.
|
|
|
|
// After "std::string S; S." we might suggest members of std::string.
|
|
|
|
// Signature help describes the parameters of a function as you type them.
|
|
|
|
//
|
2018-08-15 00:03:32 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2017-12-04 21:49:59 +08:00
|
|
|
#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_CODECOMPLETE_H
|
|
|
|
#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_CODECOMPLETE_H
|
|
|
|
|
2021-01-10 23:32:00 +08:00
|
|
|
#include "ASTSignals.h"
|
2020-06-03 16:34:05 +08:00
|
|
|
#include "Compiler.h"
|
2018-05-15 23:29:32 +08:00
|
|
|
#include "Headers.h"
|
2017-12-04 21:49:59 +08:00
|
|
|
#include "Protocol.h"
|
2020-03-04 20:25:02 +08:00
|
|
|
#include "Quality.h"
|
2017-12-20 00:50:37 +08:00
|
|
|
#include "index/Index.h"
|
2019-02-28 21:23:03 +08:00
|
|
|
#include "index/Symbol.h"
|
2019-02-28 20:31:49 +08:00
|
|
|
#include "index/SymbolOrigin.h"
|
[clangd] Move non-clang base pieces into separate support/ lib. NFCI
Summary:
This enforces layering, reduces a sprawling clangd/ directory, and makes life
easier for embedders.
Reviewers: kbobyrev
Subscribers: mgorny, ilya-biryukov, javed.absar, MaskRay, jkorous, arphaman, jfb, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D79014
2020-04-28 23:49:17 +08:00
|
|
|
#include "support/Logger.h"
|
2020-05-02 20:53:47 +08:00
|
|
|
#include "support/Markup.h"
|
[clangd] Move non-clang base pieces into separate support/ lib. NFCI
Summary:
This enforces layering, reduces a sprawling clangd/ directory, and makes life
easier for embedders.
Reviewers: kbobyrev
Subscribers: mgorny, ilya-biryukov, javed.absar, MaskRay, jkorous, arphaman, jfb, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D79014
2020-04-28 23:49:17 +08:00
|
|
|
#include "support/Path.h"
|
2018-07-23 18:56:37 +08:00
|
|
|
#include "clang/Sema/CodeCompleteConsumer.h"
|
2017-12-04 21:49:59 +08:00
|
|
|
#include "clang/Sema/CodeCompleteOptions.h"
|
|
|
|
#include "clang/Tooling/CompilationDatabase.h"
|
[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
|
|
|
#include "llvm/ADT/Optional.h"
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
#include "llvm/ADT/SmallVector.h"
|
[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
|
|
|
#include "llvm/ADT/StringRef.h"
|
|
|
|
#include "llvm/Support/Error.h"
|
2020-03-04 20:25:02 +08:00
|
|
|
#include <functional>
|
[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
|
|
|
#include <future>
|
2017-12-04 21:49:59 +08:00
|
|
|
|
|
|
|
namespace clang {
|
[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
|
|
|
class NamedDecl;
|
2017-12-04 21:49:59 +08:00
|
|
|
namespace clangd {
|
2019-09-03 23:34:47 +08:00
|
|
|
struct PreambleData;
|
2020-03-04 20:25:02 +08:00
|
|
|
struct CodeCompletion;
|
2017-12-04 21:49:59 +08:00
|
|
|
|
|
|
|
struct CodeCompleteOptions {
|
|
|
|
/// Returns options that can be passed to clang's completion engine.
|
|
|
|
clang::CodeCompleteOptions getClangCompleteOpts() const;
|
|
|
|
|
|
|
|
/// When true, completion items will contain expandable code snippets in
|
|
|
|
/// completion (e.g. `return ${1:expression}` or `foo(${1:int a}, ${2:int
|
|
|
|
/// b})).
|
|
|
|
bool EnableSnippets = false;
|
|
|
|
|
|
|
|
/// Include results that are not legal completions in the current context.
|
|
|
|
/// For example, private members are usually inaccessible.
|
|
|
|
bool IncludeIneligibleResults = false;
|
|
|
|
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
/// Combine overloads into a single completion item where possible.
|
2020-01-03 02:41:43 +08:00
|
|
|
/// If none, the implementation may choose an appropriate behavior.
|
2019-07-09 01:27:15 +08:00
|
|
|
/// (In practice, ClangdLSPServer enables bundling if the client claims
|
|
|
|
/// to supports signature help).
|
|
|
|
llvm::Optional<bool> BundleOverloads;
|
[clangd] Add option to fold overloads into a single completion item.
Summary:
Adds a CodeCompleteOption to folds together compatible function/method overloads
into a single item. This feels pretty good (for editors with signatureHelp
support), but has limitations.
This happens in the code completion merge step, so there may be inconsistencies
(e.g. if only one overload made it into the index result list, no folding).
We don't want to bundle together completions that have different side-effects
(include insertion), because we can't constructo a coherent CompletionItem.
This may be confusing for users, as the reason for non-bundling may not
be immediately obvious. (Also, the implementation seems a little fragile)
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47957
llvm-svn: 334822
2018-06-15 19:06:29 +08:00
|
|
|
|
2017-12-04 21:49:59 +08:00
|
|
|
/// Limit the number of results returned (0 means no limit).
|
|
|
|
/// If more results are available, we set CompletionList.isIncomplete.
|
|
|
|
size_t Limit = 0;
|
2017-12-20 00:50:37 +08:00
|
|
|
|
2020-04-30 16:49:32 +08:00
|
|
|
/// Whether to present doc comments as plain-text or markdown.
|
|
|
|
MarkupKind DocumentationFormat = MarkupKind::PlainText;
|
|
|
|
|
2019-04-10 20:15:35 +08:00
|
|
|
enum IncludeInsertion {
|
|
|
|
IWYU,
|
|
|
|
NeverInsert,
|
|
|
|
} InsertIncludes = IncludeInsertion::IWYU;
|
|
|
|
|
2018-06-15 21:34:18 +08:00
|
|
|
/// A visual indicator to prepend to the completion label to indicate whether
|
|
|
|
/// completion result would trigger an #include insertion or not.
|
|
|
|
struct IncludeInsertionIndicator {
|
|
|
|
std::string Insert = "•";
|
|
|
|
std::string NoInsert = " ";
|
|
|
|
} IncludeIndicator;
|
|
|
|
|
2018-07-05 14:20:41 +08:00
|
|
|
/// Expose origins of completion items in the label (for debugging).
|
|
|
|
bool ShowOrigins = false;
|
|
|
|
|
2017-12-20 00:50:37 +08:00
|
|
|
// Populated internally by clangd, do not set.
|
|
|
|
/// If `Index` is set, it is used to augment the code completion
|
|
|
|
/// results.
|
|
|
|
/// FIXME(ioeric): we might want a better way to pass the index around inside
|
|
|
|
/// clangd.
|
|
|
|
const SymbolIndex *Index = nullptr;
|
2018-08-08 16:59:29 +08:00
|
|
|
|
2021-01-10 23:32:00 +08:00
|
|
|
const ASTSignals *MainFileSignals = nullptr;
|
2018-08-08 16:59:29 +08:00
|
|
|
/// Include completions that require small corrections, e.g. change '.' to
|
|
|
|
/// '->' on member access etc.
|
|
|
|
bool IncludeFixIts = false;
|
2018-08-17 23:42:54 +08:00
|
|
|
|
|
|
|
/// Whether to generate snippets for function arguments on code-completion.
|
|
|
|
/// Needs snippets to be enabled as well.
|
|
|
|
bool EnableFunctionArgSnippets = true;
|
2018-09-28 02:46:00 +08:00
|
|
|
|
|
|
|
/// Whether to include index symbols that are not defined in the scopes
|
|
|
|
/// visible from the code completion point. This applies in contexts without
|
|
|
|
/// explicit scope qualifiers.
|
|
|
|
///
|
|
|
|
/// Such completions can insert scope qualifiers.
|
|
|
|
bool AllScopes = false;
|
[clangd] Add fallback mode for code completion when compile command or preamble is not ready.
Summary:
When calling TUScehduler::runWithPreamble (e.g. in code compleiton), allow
entering a fallback mode when compile command or preamble is not ready, instead of
waiting. This allows clangd to perform naive code completion e.g. using identifiers
in the current file or symbols in the index.
This patch simply returns empty result for code completion in fallback mode. Identifier-based
plus more advanced index-based completion will be added in followup patches.
Reviewers: ilya-biryukov, sammccall
Reviewed By: sammccall
Subscribers: sammccall, javed.absar, MaskRay, jkorous, arphaman, kadircet, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59811
llvm-svn: 357916
2019-04-08 22:53:16 +08:00
|
|
|
|
2019-05-21 21:40:31 +08:00
|
|
|
/// Whether to use the clang parser, or fallback to text-based completion
|
|
|
|
/// (using identifiers in the current file and symbol indexes).
|
|
|
|
enum CodeCompletionParse {
|
|
|
|
/// Block until we can run the parser (e.g. preamble is built).
|
|
|
|
/// Return an error if this fails.
|
|
|
|
AlwaysParse,
|
|
|
|
/// Run the parser if inputs (preamble) are ready.
|
|
|
|
/// Otherwise, use text-based completion.
|
|
|
|
ParseIfReady,
|
|
|
|
/// Always use text-based completion.
|
|
|
|
NeverParse,
|
|
|
|
} RunParser = ParseIfReady;
|
2020-03-04 20:25:02 +08:00
|
|
|
|
|
|
|
/// Callback invoked on all CompletionCandidate after they are scored and
|
|
|
|
/// before they are ranked (by -Score). Thus the results are yielded in
|
|
|
|
/// arbitrary order.
|
|
|
|
///
|
|
|
|
/// This callbacks allows capturing various internal structures used by clangd
|
|
|
|
/// during code completion. Eg: Symbol quality and relevance signals.
|
|
|
|
std::function<void(const CodeCompletion &, const SymbolQualitySignals &,
|
|
|
|
const SymbolRelevanceSignals &, float Score)>
|
|
|
|
RecordCCResult;
|
[clangd] Use Decision Forest to score code completions.
By default clangd will score a code completion item using heuristics model.
Scoring can be done by Decision Forest model by passing `--ranking_model=decision_forest` to
clangd.
Features omitted from the model:
- `NameMatch` is excluded because the final score must be multiplicative in `NameMatch` to allow rescoring by the editor.
- `NeedsFixIts` is excluded because the generating dataset that needs 'fixits' is non-trivial.
There are multiple ways (heuristics) to combine the above two features with the prediction of the DF:
- `NeedsFixIts` is used as is with a penalty of `0.5`.
Various alternatives of combining NameMatch `N` and Decision forest Prediction `P`
- N * scale(P, 0, 1): Linearly scale the output of model to range [0, 1]
- N * a^P:
- More natural: Prediction of each Decision Tree can be considered as a multiplicative boost (like NameMatch)
- Ordering is independent of the absolute value of P. Order of two items is proportional to `a^{difference in model prediction score}`. Higher `a` gives higher weightage to model output as compared to NameMatch score.
Baseline MRR = 0.619
MRR for various combinations:
N * P = 0.6346, advantage%=2.5768
N * 1.1^P = 0.6600, advantage%=6.6853
N * **1.2**^P = 0.6669, advantage%=**7.8005**
N * **1.3**^P = 0.6668, advantage%=**7.7795**
N * **1.4**^P = 0.6659, advantage%=**7.6270**
N * 1.5^P = 0.6646, advantage%=7.4200
N * 1.6^P = 0.6636, advantage%=7.2671
N * 1.7^P = 0.6629, advantage%=7.1450
N * 2^P = 0.6612, advantage%=6.8673
N * 2.5^P = 0.6598, advantage%=6.6491
N * 3^P = 0.6590, advantage%=6.5242
N * scaled[0, 1] = 0.6465, advantage%=4.5054
Differential Revision: https://reviews.llvm.org/D88281
2020-09-22 13:56:08 +08:00
|
|
|
|
|
|
|
/// Model to use for ranking code completion candidates.
|
|
|
|
enum CodeCompletionRankingModel {
|
|
|
|
Heuristics,
|
|
|
|
DecisionForest,
|
2021-03-02 23:36:11 +08:00
|
|
|
} RankingModel = DecisionForest;
|
[clangd] Use Decision Forest to score code completions.
By default clangd will score a code completion item using heuristics model.
Scoring can be done by Decision Forest model by passing `--ranking_model=decision_forest` to
clangd.
Features omitted from the model:
- `NameMatch` is excluded because the final score must be multiplicative in `NameMatch` to allow rescoring by the editor.
- `NeedsFixIts` is excluded because the generating dataset that needs 'fixits' is non-trivial.
There are multiple ways (heuristics) to combine the above two features with the prediction of the DF:
- `NeedsFixIts` is used as is with a penalty of `0.5`.
Various alternatives of combining NameMatch `N` and Decision forest Prediction `P`
- N * scale(P, 0, 1): Linearly scale the output of model to range [0, 1]
- N * a^P:
- More natural: Prediction of each Decision Tree can be considered as a multiplicative boost (like NameMatch)
- Ordering is independent of the absolute value of P. Order of two items is proportional to `a^{difference in model prediction score}`. Higher `a` gives higher weightage to model output as compared to NameMatch score.
Baseline MRR = 0.619
MRR for various combinations:
N * P = 0.6346, advantage%=2.5768
N * 1.1^P = 0.6600, advantage%=6.6853
N * **1.2**^P = 0.6669, advantage%=**7.8005**
N * **1.3**^P = 0.6668, advantage%=**7.7795**
N * **1.4**^P = 0.6659, advantage%=**7.6270**
N * 1.5^P = 0.6646, advantage%=7.4200
N * 1.6^P = 0.6636, advantage%=7.2671
N * 1.7^P = 0.6629, advantage%=7.1450
N * 2^P = 0.6612, advantage%=6.8673
N * 2.5^P = 0.6598, advantage%=6.6491
N * 3^P = 0.6590, advantage%=6.5242
N * scaled[0, 1] = 0.6465, advantage%=4.5054
Differential Revision: https://reviews.llvm.org/D88281
2020-09-22 13:56:08 +08:00
|
|
|
|
2020-10-23 16:19:53 +08:00
|
|
|
/// Callback used to score a CompletionCandidate if DecisionForest ranking
|
|
|
|
/// model is enabled.
|
|
|
|
/// This allows us to inject experimental models and compare them with
|
|
|
|
/// baseline model using A/B testing.
|
|
|
|
std::function<DecisionForestScores(
|
|
|
|
const SymbolQualitySignals &, const SymbolRelevanceSignals &, float Base)>
|
|
|
|
DecisionForestScorer = &evaluateDecisionForest;
|
[clangd] Use Decision Forest to score code completions.
By default clangd will score a code completion item using heuristics model.
Scoring can be done by Decision Forest model by passing `--ranking_model=decision_forest` to
clangd.
Features omitted from the model:
- `NameMatch` is excluded because the final score must be multiplicative in `NameMatch` to allow rescoring by the editor.
- `NeedsFixIts` is excluded because the generating dataset that needs 'fixits' is non-trivial.
There are multiple ways (heuristics) to combine the above two features with the prediction of the DF:
- `NeedsFixIts` is used as is with a penalty of `0.5`.
Various alternatives of combining NameMatch `N` and Decision forest Prediction `P`
- N * scale(P, 0, 1): Linearly scale the output of model to range [0, 1]
- N * a^P:
- More natural: Prediction of each Decision Tree can be considered as a multiplicative boost (like NameMatch)
- Ordering is independent of the absolute value of P. Order of two items is proportional to `a^{difference in model prediction score}`. Higher `a` gives higher weightage to model output as compared to NameMatch score.
Baseline MRR = 0.619
MRR for various combinations:
N * P = 0.6346, advantage%=2.5768
N * 1.1^P = 0.6600, advantage%=6.6853
N * **1.2**^P = 0.6669, advantage%=**7.8005**
N * **1.3**^P = 0.6668, advantage%=**7.7795**
N * **1.4**^P = 0.6659, advantage%=**7.6270**
N * 1.5^P = 0.6646, advantage%=7.4200
N * 1.6^P = 0.6636, advantage%=7.2671
N * 1.7^P = 0.6629, advantage%=7.1450
N * 2^P = 0.6612, advantage%=6.8673
N * 2.5^P = 0.6598, advantage%=6.6491
N * 3^P = 0.6590, advantage%=6.5242
N * scaled[0, 1] = 0.6465, advantage%=4.5054
Differential Revision: https://reviews.llvm.org/D88281
2020-09-22 13:56:08 +08:00
|
|
|
/// Weight for combining NameMatch and Prediction of DecisionForest.
|
|
|
|
/// CompletionScore is NameMatch * pow(Base, Prediction).
|
|
|
|
/// The optimal value of Base largely depends on the semantics of the model
|
|
|
|
/// and prediction score (e.g. algorithm used during training, number of
|
|
|
|
/// trees, etc.). Usually if the range of Prediciton is [-20, 20] then a Base
|
|
|
|
/// in [1.2, 1.7] works fine.
|
2020-10-23 16:19:53 +08:00
|
|
|
/// Semantics: E.g. For Base = 1.3, if the Prediciton score reduces by 2.6
|
|
|
|
/// points then completion score reduces by 50% or 1.3^(-2.6).
|
[clangd] Use Decision Forest to score code completions.
By default clangd will score a code completion item using heuristics model.
Scoring can be done by Decision Forest model by passing `--ranking_model=decision_forest` to
clangd.
Features omitted from the model:
- `NameMatch` is excluded because the final score must be multiplicative in `NameMatch` to allow rescoring by the editor.
- `NeedsFixIts` is excluded because the generating dataset that needs 'fixits' is non-trivial.
There are multiple ways (heuristics) to combine the above two features with the prediction of the DF:
- `NeedsFixIts` is used as is with a penalty of `0.5`.
Various alternatives of combining NameMatch `N` and Decision forest Prediction `P`
- N * scale(P, 0, 1): Linearly scale the output of model to range [0, 1]
- N * a^P:
- More natural: Prediction of each Decision Tree can be considered as a multiplicative boost (like NameMatch)
- Ordering is independent of the absolute value of P. Order of two items is proportional to `a^{difference in model prediction score}`. Higher `a` gives higher weightage to model output as compared to NameMatch score.
Baseline MRR = 0.619
MRR for various combinations:
N * P = 0.6346, advantage%=2.5768
N * 1.1^P = 0.6600, advantage%=6.6853
N * **1.2**^P = 0.6669, advantage%=**7.8005**
N * **1.3**^P = 0.6668, advantage%=**7.7795**
N * **1.4**^P = 0.6659, advantage%=**7.6270**
N * 1.5^P = 0.6646, advantage%=7.4200
N * 1.6^P = 0.6636, advantage%=7.2671
N * 1.7^P = 0.6629, advantage%=7.1450
N * 2^P = 0.6612, advantage%=6.8673
N * 2.5^P = 0.6598, advantage%=6.6491
N * 3^P = 0.6590, advantage%=6.5242
N * scaled[0, 1] = 0.6465, advantage%=4.5054
Differential Revision: https://reviews.llvm.org/D88281
2020-09-22 13:56:08 +08:00
|
|
|
float DecisionForestBase = 1.3f;
|
2017-12-04 21:49:59 +08:00
|
|
|
};
|
|
|
|
|
2018-06-29 22:47:57 +08:00
|
|
|
// Semi-structured representation of a code-complete suggestion for our C++ API.
|
|
|
|
// We don't use the LSP structures here (unlike most features) as we want
|
|
|
|
// to expose more data to allow for more precise testing and evaluation.
|
|
|
|
struct CodeCompletion {
|
|
|
|
// The unqualified name of the symbol or other completion item.
|
|
|
|
std::string Name;
|
|
|
|
// The scope qualifier for the symbol name. e.g. "ns1::ns2::"
|
|
|
|
// Empty for non-symbol completions. Not inserted, but may be displayed.
|
|
|
|
std::string Scope;
|
|
|
|
// Text that must be inserted before the name, and displayed (e.g. base::).
|
|
|
|
std::string RequiredQualifier;
|
|
|
|
// Details to be displayed following the name. Not inserted.
|
|
|
|
std::string Signature;
|
|
|
|
// Text to be inserted following the name, in snippet format.
|
|
|
|
std::string SnippetSuffix;
|
|
|
|
// Type to be displayed for this completion.
|
|
|
|
std::string ReturnType;
|
2020-04-30 16:49:32 +08:00
|
|
|
// The parsed documentation comment.
|
|
|
|
llvm::Optional<markup::Document> Documentation;
|
2018-06-29 22:47:57 +08:00
|
|
|
CompletionItemKind Kind = CompletionItemKind::Missing;
|
|
|
|
// This completion item may represent several symbols that can be inserted in
|
|
|
|
// the same way, such as function overloads. In this case BundleSize > 1, and
|
|
|
|
// the following fields are summaries:
|
|
|
|
// - Signature is e.g. "(...)" for functions.
|
|
|
|
// - SnippetSuffix is similarly e.g. "(${0})".
|
|
|
|
// - ReturnType may be empty
|
|
|
|
// - Documentation may be from one symbol, or a combination of several
|
|
|
|
// Other fields should apply equally to all bundled completions.
|
2018-07-02 19:13:16 +08:00
|
|
|
unsigned BundleSize = 1;
|
2018-07-05 14:20:41 +08:00
|
|
|
SymbolOrigin Origin = SymbolOrigin::Unknown;
|
[clangd] Support multiple #include headers in one symbol.
Summary:
Currently, a symbol can have only one #include header attached, which
might not work well if the symbol can be imported via different #includes depending
on where it's used. This patch stores multiple #include headers (with # references)
for each symbol, so that CodeCompletion can decide which include to insert.
In this patch, code completion simply picks the most popular include as the default inserted header. We also return all possible includes and their edits in the `CodeCompletion` results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgrang, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51291
llvm-svn: 341304
2018-09-03 18:18:21 +08:00
|
|
|
|
|
|
|
struct IncludeCandidate {
|
|
|
|
// The header through which this symbol could be included.
|
|
|
|
// Quoted string as expected by an #include directive, e.g. "<memory>".
|
|
|
|
// Empty for non-symbol completions, or when not known.
|
|
|
|
std::string Header;
|
|
|
|
// Present if Header should be inserted to use this item.
|
|
|
|
llvm::Optional<TextEdit> Insertion;
|
|
|
|
};
|
|
|
|
// All possible include headers ranked by preference. By default, the first
|
|
|
|
// include is used.
|
|
|
|
// If we've bundled together overloads that have different sets of includes,
|
|
|
|
// thse includes may not be accurate for all of them.
|
|
|
|
llvm::SmallVector<IncludeCandidate, 1> Includes;
|
2018-06-29 22:47:57 +08:00
|
|
|
|
2018-08-08 16:59:29 +08:00
|
|
|
/// Holds information about small corrections that needs to be done. Like
|
|
|
|
/// converting '->' to '.' on member access.
|
|
|
|
std::vector<TextEdit> FixIts;
|
|
|
|
|
2018-08-13 16:23:01 +08:00
|
|
|
/// Holds the range of the token we are going to replace with this completion.
|
|
|
|
Range CompletionTokenRange;
|
|
|
|
|
2018-06-29 22:47:57 +08:00
|
|
|
// Scores are used to rank completion items.
|
|
|
|
struct Scores {
|
|
|
|
// The score that items are ranked by.
|
|
|
|
float Total = 0.f;
|
|
|
|
|
|
|
|
// The finalScore with the fuzzy name match score excluded.
|
|
|
|
// When filtering client-side, editors should calculate the new fuzzy score,
|
|
|
|
// whose scale is 0-1 (with 1 = prefix match, special case 2 = exact match),
|
|
|
|
// and recompute finalScore = fuzzyScore * symbolScore.
|
|
|
|
float ExcludingName = 0.f;
|
|
|
|
|
|
|
|
// Component scores that contributed to the final score:
|
|
|
|
|
|
|
|
// Quality describes how important we think this candidate is,
|
|
|
|
// independent of the query.
|
|
|
|
// e.g. symbols with lots of incoming references have higher quality.
|
|
|
|
float Quality = 0.f;
|
|
|
|
// Relevance describes how well this candidate matched the query.
|
|
|
|
// e.g. symbols from nearby files have higher relevance.
|
|
|
|
float Relevance = 0.f;
|
|
|
|
};
|
|
|
|
Scores Score;
|
|
|
|
|
2018-09-07 02:52:26 +08:00
|
|
|
/// Indicates if this item is deprecated.
|
|
|
|
bool Deprecated = false;
|
|
|
|
|
2018-06-29 22:47:57 +08:00
|
|
|
// Serialize this to an LSP completion item. This is a lossy operation.
|
|
|
|
CompletionItem render(const CodeCompleteOptions &) const;
|
|
|
|
};
|
2018-07-02 19:13:16 +08:00
|
|
|
raw_ostream &operator<<(raw_ostream &, const CodeCompletion &);
|
2018-06-29 22:47:57 +08:00
|
|
|
struct CodeCompleteResult {
|
|
|
|
std::vector<CodeCompletion> Completions;
|
|
|
|
bool HasMore = false;
|
2018-07-23 18:56:37 +08:00
|
|
|
CodeCompletionContext::Kind Context = CodeCompletionContext::CCC_Other;
|
2020-02-10 18:52:42 +08:00
|
|
|
// The text that is being directly completed.
|
|
|
|
// Example: foo.pb^ -> foo.push_back()
|
|
|
|
// ~~
|
|
|
|
// Typically matches the textEdit.range of Completions, but not guaranteed to.
|
|
|
|
llvm::Optional<Range> CompletionRange;
|
2019-05-06 20:03:26 +08:00
|
|
|
// Usually the source will be parsed with a real C++ parser.
|
|
|
|
// But heuristics may be used instead if e.g. the preamble is not ready.
|
|
|
|
bool RanParser = true;
|
2018-06-29 22:47:57 +08:00
|
|
|
};
|
2018-07-02 19:13:16 +08:00
|
|
|
raw_ostream &operator<<(raw_ostream &, const CodeCompleteResult &);
|
2018-06-29 22:47:57 +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
|
|
|
/// A speculative and asynchronous fuzzy find index request (based on cached
|
|
|
|
/// request) that can be sent before parsing sema. This would reduce completion
|
|
|
|
/// latency if the speculation succeeds.
|
|
|
|
struct SpeculativeFuzzyFind {
|
|
|
|
/// A cached request from past code completions.
|
|
|
|
/// Set by caller of `codeComplete()`.
|
|
|
|
llvm::Optional<FuzzyFindRequest> CachedReq;
|
|
|
|
/// The actual request used by `codeComplete()`.
|
|
|
|
/// Set by `codeComplete()`. This can be used by callers to update cache.
|
|
|
|
llvm::Optional<FuzzyFindRequest> NewReq;
|
|
|
|
/// The result is consumed by `codeComplete()` if speculation succeeded.
|
|
|
|
/// NOTE: the destructor will wait for the async call to finish.
|
|
|
|
std::future<SymbolSlab> Result;
|
|
|
|
};
|
|
|
|
|
2019-04-11 17:36:36 +08:00
|
|
|
/// Gets code completions at a specified \p Pos in \p FileName.
|
|
|
|
///
|
|
|
|
/// If \p Preamble is nullptr, this runs code completion without compiling the
|
|
|
|
/// code.
|
|
|
|
///
|
[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
|
|
|
/// If \p SpecFuzzyFind is set, a speculative and asynchronous fuzzy find index
|
|
|
|
/// request (based on cached request) will be run before parsing sema. In case
|
|
|
|
/// the speculative result is used by code completion (e.g. speculation failed),
|
|
|
|
/// the speculative result is not consumed, and `SpecFuzzyFind` is only
|
|
|
|
/// destroyed when the async request finishes.
|
2020-06-03 16:34:05 +08:00
|
|
|
CodeCompleteResult codeComplete(PathRef FileName, Position Pos,
|
2018-10-02 18:43:55 +08:00
|
|
|
const PreambleData *Preamble,
|
2020-06-03 16:34:05 +08:00
|
|
|
const ParseInputs &ParseInput,
|
[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
|
|
|
CodeCompleteOptions Opts,
|
|
|
|
SpeculativeFuzzyFind *SpecFuzzyFind = nullptr);
|
2017-12-04 21:49:59 +08:00
|
|
|
|
|
|
|
/// Get signature help at a specified \p Pos in \p FileName.
|
2020-06-03 16:34:05 +08:00
|
|
|
SignatureHelp signatureHelp(PathRef FileName, Position Pos,
|
|
|
|
const PreambleData &Preamble,
|
2021-12-09 16:36:04 +08:00
|
|
|
const ParseInputs &ParseInput,
|
|
|
|
MarkupKind DocumentationFormat);
|
2017-12-04 21:49:59 +08:00
|
|
|
|
[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
|
|
|
// For index-based completion, we only consider:
|
|
|
|
// * symbols in namespaces or translation unit scopes (e.g. no class
|
|
|
|
// members, no locals)
|
|
|
|
// * enum constants in unscoped enum decl (e.g. "red" in "enum {red};")
|
|
|
|
// * primary templates (no specializations)
|
|
|
|
// For the other cases, we let Clang do the completion because it does not
|
|
|
|
// need any non-local information and it will be much better at following
|
|
|
|
// lookup rules. Other symbols still appear in the index for other purposes,
|
|
|
|
// like workspace/symbols or textDocument/definition, but are not used for code
|
|
|
|
// completion.
|
|
|
|
bool isIndexedForCodeCompletion(const NamedDecl &ND, ASTContext &ASTCtx);
|
[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
|
|
|
|
2019-04-10 19:50:40 +08:00
|
|
|
// Text immediately before the completion point that should be completed.
|
|
|
|
// This is heuristically derived from the source code, and is used when:
|
|
|
|
// - semantic analysis fails
|
|
|
|
// - semantic analysis may be slow, and we speculatively query the index
|
|
|
|
struct CompletionPrefix {
|
|
|
|
// The unqualified partial name.
|
|
|
|
// If there is none, begin() == end() == completion position.
|
|
|
|
llvm::StringRef Name;
|
|
|
|
// The spelled scope qualifier, such as Foo::.
|
|
|
|
// If there is none, begin() == end() == Name.begin().
|
|
|
|
llvm::StringRef Qualifier;
|
|
|
|
};
|
|
|
|
// Heuristically parses before Offset to determine what should be completed.
|
|
|
|
CompletionPrefix guessCompletionPrefix(llvm::StringRef Content,
|
|
|
|
unsigned Offset);
|
[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
|
|
|
|
2020-05-06 07:39:59 +08:00
|
|
|
// Whether it makes sense to complete at the point based on typed characters.
|
|
|
|
// For instance, we implicitly trigger at `a->^` but not at `a>^`.
|
|
|
|
bool allowImplicitCompletion(llvm::StringRef Content, unsigned Offset);
|
|
|
|
|
2017-12-04 21:49:59 +08:00
|
|
|
} // namespace clangd
|
|
|
|
} // namespace clang
|
|
|
|
|
2018-08-15 00:03:32 +08:00
|
|
|
#endif // LLVM_CLANG_TOOLS_EXTRA_CLANGD_CODECOMPLETE_H
|