574: refactor completions to use TextEdit instead of InsertText r=matklad a=gfreezy
1. migrate from `insertText` to `TextEdit` from `CompleteItem`
2. use `insta` to test completions
Co-authored-by: gfreezy <gfreezy@gmail.com>
517: gracefully handle cycles in crate graph r=matklad a=matklad
518: Add an explanatory message when we use the Query fallback r=matklad a=DJMcNab
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/269.
There is no good way to explain it for go_to_def, so I've just fallen back on to_vec.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
Co-authored-by: DJMcNab <36049421+djmcnab@users.noreply.github.com>
505: Inherent methods r=matklad a=flodiebold
This adds resolution, type checking and completion for inherent methods.
The main open question here is the caching, I think. I'm not sure whether we should be caching method resolutions in a more fine grained way (currently we just build a hash map of types -> impl blocks, and iterate through all potential impl blocks when looking for a method).
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
500: Code lens support for running tests r=matklad a=kjeremy
Supports running individual and mod tests.
I feel like this kind of abuses the `Runnables` infrastructure but it works. Maybe later on down the line we should introduce a struct that is really just a tuple of binary, arguments, and environment and pass that back to the client instead. `run_single.ts` is just a paired down version of `runnables.ts` and there is duplication because I think run_single will probably change independent of runnables.
Co-authored-by: Jeremy A. Kolb <jkolb@ara.com>
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
If we index gazillion libraries simultaneously, we fill the threadpool
and so the main loop fails to turn, although there isn't really any
significant blocking inside the loop itself.
