diff options
Diffstat (limited to 'crates/ide_completion/src/lib.rs')
-rw-r--r-- | crates/ide_completion/src/lib.rs | 30 |
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. | ||
107 | pub fn completions( | 137 | pub fn completions( |
108 | db: &RootDatabase, | 138 | db: &RootDatabase, |
109 | config: &CompletionConfig, | 139 | config: &CompletionConfig, |