| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
546: replace `assert_dbg_eq` with Insta r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
485: Add type inference for a bunch of primitives r=flodiebold a=marcusklaas
This PR adds inference for `&str`, `&[u8]`, `char`, `bool`, floats and integers. For floats and integers it uses type variables to infer the exact type, i.e. `u32`, from context when it's not annotated explicitly.
I'm not quite happy with the implementation yet, but I think it mostly works now.
Co-authored-by: Marcus Klaas de Vries <[email protected]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
|/ / |
|
| | |
|
| | |
|
|/ |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
532: fix go to parent module r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|/ |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
520: Imprement tuple inference r=flodiebold a=h-michael
related #394
I'm sorry I'm late.
I try implementing array inference next.
Co-authored-by: Hirokazu Hata <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
| |
Small tweak for #518
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
Co-authored-by: DJMcNab <[email protected]>
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
rust-lang/rust has absolutely weird setup with rustc-workspace-shim,
which leads to real cycles.
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | | |
519: support ref-patterns r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |/ |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
513: Add bench runnable and code lens r=matklad a=kjeremy
Co-authored-by: Jeremy Kolb <[email protected]>
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
Co-authored-by: Jeremy Kolb <[email protected]>
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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 <[email protected]>
|
| | |/
| |/| |
|
|/ / |
|
| |
| |
| |
| | |
MarkedString is deprecated
|
| |
| |
| |
| |
| |
| |
| | |
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).
|