bors[bot] [Sun, 13 Jan 2019 16:59:35 +0000 (16:59 +0000)]
Merge #527
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.
bors[bot] [Sat, 12 Jan 2019 21:18:14 +0000 (21:18 +0000)]
Merge #505
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).
bors[bot] [Sat, 12 Jan 2019 18:56:11 +0000 (18:56 +0000)]
Merge #500
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>
bors[bot] [Sat, 12 Jan 2019 15:09:33 +0000 (15:09 +0000)]
Merge #506
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.
bors[bot] [Fri, 11 Jan 2019 22:49:32 +0000 (22:49 +0000)]
Merge #491
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).
Florian Diebold [Thu, 10 Jan 2019 21:49:43 +0000 (22:49 +0100)]
Fix assertion error in unification (hopefully)
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).
Aleksey Kladov [Fri, 11 Jan 2019 13:58:01 +0000 (16:58 +0300)]
prioritize event handing over indexing
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.
bors[bot] [Thu, 10 Jan 2019 20:44:21 +0000 (20:44 +0000)]
Merge #463
463: Use name resolution for goto definition r=matklad a=flodiebold
This tries proper name resolution before falling back on the index.
@matklad There was currently no way of getting the location of a `DefId` from outside `ra_hir`. I added something, but it's probably not the best API, maybe you have a better idea?
projects / rust.git / log