| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
527: goto defenition works for type-inferred methods r=flodiebold a=matklad
This uses type inference results for `goto method` functionality.
This is achieved by adding another map to `InferenceResult`. I wonder how we should handle this long-term... The pattern seems to be "we are doing some analysis, and we produce some stuff as a by-product, and IDE would like to use the stuff". Ideally, adding an additional bit of info shouldn't require threading it through all data structures.
I kinda like how Kotlin deals with this problem. They have this [`BindingContext`](https://github.com/JetBrains/kotlin/blob/72e351a0e3610051fe4222dca4e1eeedf7ae45da/compiler/frontend/src/org/jetbrains/kotlin/resolve/BindingContext.java#L122) thing, which is basically an [`AnyMap`](https://github.com/JetBrains/kotlin/blob/72e351a0e3610051fe4222dca4e1eeedf7ae45da/compiler/frontend/src/org/jetbrains/kotlin/resolve/BindingContext.java#L122) of HashMaps.
Deep in the compiler guts, they [record the info](https://github.com/JetBrains/kotlin/blob/ba6da7c40a6cc502508faf6e04fa105b96bc7777/compiler/frontend/src/org/jetbrains/kotlin/resolve/calls/tasks/TracingStrategyForInvoke.java#L70-L75) into the map, using a type key, a value key and a value.
Then the IDE [reads this map](https://github.com/JetBrains/kotlin/blob/ba6da7c40a6cc502508faf6e04fa105b96bc7777/idea/src/org/jetbrains/kotlin/idea/inspections/RedundantNotNullExtensionReceiverOfInlineInspection.kt#L64) (via a [helper](https://github.com/JetBrains/kotlin/blob/ba6da7c40a6cc502508faf6e04fa105b96bc7777/compiler/frontend/src/org/jetbrains/kotlin/resolve/calls/util/callUtil.kt#L178-L180)). The stuff in between does not know that this type-key exists, unless it inspects it.
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| | |
526: fix indent caclulation 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]>
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
522: Tweak message shown for query fallback r=DJMcNab a=killercup
Small tweak for #518
Co-authored-by: Pascal Hertleif <[email protected]>
|
|/ /
| |
| |
| | |
Small tweak for #518
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
521: refresh docs r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| | |
|
| | | |
| \ | |
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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]>
|
| | | |
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | | |
514: npm fix run r=matklad a=kjeremy
Co-authored-by: Jeremy Kolb <[email protected]>
|
| |/ |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
515: Fix typos 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]>
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | | |
`--depth 1` will make a shallow clone, of master branch only.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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]>
|
| | |/
| |/| |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
501: Switch hover to use MarkupContent r=matklad a=kjeremy
MarkedString is deprecated
Co-authored-by: Jeremy Kolb <[email protected]>
|
|/ /
| |
| |
| | |
MarkedString is deprecated
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
|/ /
| |
| |
| |
| |
| |
| | |
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).
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
498: actually produce missing def kinds r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| | |
|
|/ |
|
|
|
|
| |
This is much clearer about the semantics
|