aboutsummaryrefslogtreecommitdiff
path: root/crates/ide_completion/src/lib.rs
diff options
context:
space:
mode:
Diffstat (limited to 'crates/ide_completion/src/lib.rs')
-rw-r--r--crates/ide_completion/src/lib.rs30
1 files changed, 30 insertions, 0 deletions
diff --git a/crates/ide_completion/src/lib.rs b/crates/ide_completion/src/lib.rs
index 5ac1cb48d..6f3d5c5c5 100644
--- a/crates/ide_completion/src/lib.rs
+++ b/crates/ide_completion/src/lib.rs
@@ -81,6 +81,8 @@ pub use crate::{
81// And the auto import completions, enabled with the `rust-analyzer.completion.autoimport.enable` setting and the corresponding LSP client capabilities. 81// And the auto import completions, enabled with the `rust-analyzer.completion.autoimport.enable` setting and the corresponding LSP client capabilities.
82// Those are the additional completion options with automatic `use` import and options from all project importable items, 82// Those are the additional completion options with automatic `use` import and options from all project importable items,
83// fuzzy matched agains the completion imput. 83// fuzzy matched agains the completion imput.
84//
85// image::https://user-images.githubusercontent.com/48062697/113020667-b72ab880-917a-11eb-8778-716cf26a0eb3.gif[]
84 86
85/// Main entry point for completion. We run completion as a two-phase process. 87/// Main entry point for completion. We run completion as a two-phase process.
86/// 88///
@@ -104,6 +106,34 @@ pub use crate::{
104/// `foo` *should* be present among the completion variants. Filtering by 106/// `foo` *should* be present among the completion variants. Filtering by
105/// identifier prefix/fuzzy match should be done higher in the stack, together 107/// identifier prefix/fuzzy match should be done higher in the stack, together
106/// with ordering of completions (currently this is done by the client). 108/// with ordering of completions (currently this is done by the client).
109///
110/// # Hypothetical Completion Problem
111///
112/// There's a curious unsolved problem in the current implementation. Often, you
113/// want to compute completions on a *slightly different* text document.
114///
115/// In the simplest case, when the code looks like `let x = `, you want to
116/// insert a fake identifier to get a better syntax tree: `let x = complete_me`.
117///
118/// We do this in `CompletionContext`, and it works OK-enough for *syntax*
119/// analysis. However, we might want to, eg, ask for the type of `complete_me`
120/// variable, and that's where our current infrastructure breaks down. salsa
121/// doesn't allow such "phantom" inputs.
122///
123/// Another case where this would be instrumental is macro expansion. We want to
124/// insert a fake ident and re-expand code. There's `expand_hypothetical` as a
125/// work-around for this.
126///
127/// A different use-case is completion of injection (examples and links in doc
128/// comments). When computing completion for a path in a doc-comment, you want
129/// to inject a fake path expression into the item being documented and complete
130/// that.
131///
132/// IntelliJ has CodeFragment/Context infrastructure for that. You can create a
133/// temporary PSI node, and say that the context ("parent") of this node is some
134/// existing node. Asking for, eg, type of this `CodeFragment` node works
135/// correctly, as the underlying infrastructure makes use of contexts to do
136/// analysis.
107pub fn completions( 137pub fn completions(
108 db: &RootDatabase, 138 db: &RootDatabase,
109 config: &CompletionConfig, 139 config: &CompletionConfig,