| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3954: Improve autocompletion by looking on the type and name r=matklad a=bnjjj
This tweet (https://twitter.com/tjholowaychuk/status/1248918374731714560) gaves me the idea to implement that in rust-analyzer.
Basically for this first example I made some examples when we are in a function call definition. I look on the parameter list to prioritize autocompletions for the same types and if it's the same type + the same name then it's displayed first in the completion list.
So here is a draft, first step to open a discussion and know what you think about the implementation. It works (cf tests) but maybe I can make a better implementation at some places. Be careful the code needs some refactoring to be better and concise.
PS: It was lot of fun writing this haha
Co-authored-by: Benjamin Coenen <[email protected]>
|
| |
| |
| |
| | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| |\ |
|
| |\ \
| | | |
| | | |
| | | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| |/ /
| | |
| | |
| | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| |/
|/| |
|
|/ |
|
| |
|
|
|
|
| |
This crate will hold everything to small to be worth publishing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `ty` function in code_model returned the type with placeholders for type
parameters. That's nice for printing, but not good for completion, because
placeholders won't unify with anything else: So the type we got for `HashMap`
was `HashMap<K, V, T>`, which doesn't unify with `HashMap<?, ?, RandomState>`,
so the `new` method wasn't shown.
Now we instead return `HashMap<{unknown}, {unknown}, {unknown}>`, which does
unify with the impl type. Maybe we should just expose this properly as variables
though, i.e. we'd return something like `exists<type, type, type> HashMap<?0,
?1, ?2>` (in Chalk notation). It'll make the API more complicated, but harder to
misuse. (And it would handle cases like `type TypeAlias<T> = HashMap<T, T>` more
correctly.)
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This introduces the new type -- Semantics.
Semantics maps SyntaxNodes to various semantic info, such as type,
name resolution or macro expansions.
To do so, Semantics maintains a HashMap which maps every node it saw
to the file from which the node originated. This is enough to get all
the necessary hir bits just from syntax.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
- just include the name, not e.g. `mut`
- don't return empty hints (or `_`)
|
|
|
|
| |
Signed-off-by: imtsuki <[email protected]>
|
|
|
|
| |
Signed-off-by: imtsuki <[email protected]>
|
| |
|
|
|
|
| |
macro call and macro definition
|
| |
|
|
|
|
| |
where first token != "macro_rules"
|
| |
|
|
|
|
| |
See: https://github.com/microsoft/vscode-languageserver-node/blob/master/protocol/src/protocol.callHierarchy.proposed.ts
|
| |
|
|
|
|
| |
We don't have LifetimeParam yet, but they are planned!
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|