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>
507: Fix handling of attributes in positional field lists r=matklad a=DJMcNab
First reported by @max-frai. This allows us to properly handle crates using e.g. `#[Derive(fail)]` with `#[fail(cause)]`, among other cases.
Co-authored-by: DJMcNab <36049421+djmcnab@users.noreply.github.com>
Currently, all types that we handle during inference need to be resolved as far
as possible at the time. It's maybe too brittle of an invariant; I need to think
how we can do this better. This should fix#484 though, I hope (if
it's the same case as I managed to reproduce).
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.
470: Type inference for enum variants r=flodiebold a=marcusklaas
Opened a new PR instead of https://github.com/rust-analyzer/rust-analyzer/pull/461. Totally botched that one.
I think I resolved all the issues mentioned there.
Co-authored-by: Marcus Klaas de Vries <mail@marcusklaas.nl>
