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>
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>
506: Use --force when installing the VSIX. r=DJMcNab a=DJMcNab
This might fix the extension installation, or it might not.
https://github.com/Microsoft/vscode/issues/65897#issuecomment-451749900 says we need to increase the version on every install, but I can't work out why exactly.
@egamma, can you give us some more insight?
bors r+ - It can't do any harm anyway :).
Co-authored-by: DJMcNab <36049421+djmcnab@users.noreply.github.com>
491: Fix assertion error in unification (hopefully) r=flodiebold a=flodiebold
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).
Co-authored-by: Florian Diebold <florian.diebold@freiheit.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).
