aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Implement type inference for literals (WIP)Marcus Klaas de Vries2019-01-148-5/+166
|
* Merge #537bors[bot]2019-01-1413-47/+47
|\ | | | | | | | | | | | | | | 537: switch to lsp-types r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * switch to lsp-typesAleksey Kladov2019-01-1413-47/+47
|/
* Merge #534bors[bot]2019-01-141-42/+23
|\ | | | | | | | | | | | | | | 534: Add visibility to hover r=matklad a=kjeremy Co-authored-by: Jeremy Kolb <[email protected]>
| * Remove duplicationJeremy Kolb2019-01-141-74/+23
| |
| * Add visibility to hoverJeremy Kolb2019-01-141-9/+41
|/
* Merge #533bors[bot]2019-01-131-5/+10
|\ | | | | | | | | | | | | | | 533: target_selection_range is not nullable in the implementation r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * target_selection_range is not nullable in the implementationAleksey Kladov2019-01-131-5/+10
|/
* Merge #532bors[bot]2019-01-132-2/+21
|\ | | | | | | | | | | | | | | 532: fix go to parent module r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * fix go to parent moduleAleksey Kladov2019-01-132-2/+21
| |
* | Merge #530bors[bot]2019-01-133-10/+10
|\ \ | | | | | | | | | | | | | | | | | | | | | 530: Fix some random typos r=matklad a=killercup Co-authored-by: Pascal Hertleif <[email protected]>
| * | Fix some random typosPascal Hertleif2019-01-133-10/+10
|/ /
* | Merge #529bors[bot]2019-01-132-69/+69
|\ \ | |/ |/| | | | | | | | | | | 529: :arrow_up: npm r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * :arrow_up: npmAleksey Kladov2019-01-132-69/+69
|/
* Merge #527bors[bot]2019-01-132-5/+71
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * goto defenition works for type-inferred methodsAleksey Kladov2019-01-132-5/+71
| |
* | Merge #526bors[bot]2019-01-133-11/+51
|\| | | | | | | | | | | | | | | 526: fix indent caclulation r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * fix indent caclulationAleksey Kladov2019-01-133-11/+51
|/
* note about performanceAleksey Kladov2019-01-131-7/+18
|
* Merge #520bors[bot]2019-01-136-3/+74
|\ | | | | | | | | | | | | | | | | | | | | | | 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]>
| * Fix tuple test caseHirokazu Hata2019-01-132-6/+35
| |
| * Implement tuple inferenceHirokazu Hata2019-01-132-1/+20
| |
| * Update TUPLE_EXPR grammarHirokazu Hata2019-01-132-2/+8
| |
| * Add infer tuple testHirokazu Hata2019-01-132-0/+17
| |
* | Merge #522bors[bot]2019-01-131-1/+5
|\ \ | | | | | | | | | | | | | | | | | | | | | 522: Tweak message shown for query fallback r=DJMcNab a=killercup Small tweak for #518 Co-authored-by: Pascal Hertleif <[email protected]>
| * | Tweak message shown for query fallbackPascal Hertleif2019-01-131-1/+5
|/ / | | | | | | Small tweak for #518
* | Merge #521bors[bot]2019-01-132-98/+199
|\ \ | |/ |/| | | | | | | | | | | 521: refresh docs r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * refresh docsAleksey Kladov2019-01-131-55/+166
| |
| * tweak readmeAleksey Kladov2019-01-131-43/+33
| |
| |
| \
*-. \ Merge #517 #518bors[bot]2019-01-135-51/+114
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| | * | Add an explanatory message when we use the Query fallbackDJMcNab2019-01-132-10/+36
| | | |
| * | | gracefully handle cycles in crate graphAleksey Kladov2019-01-133-41/+78
| | | | | | | | | | | | | | | | | | | | rust-lang/rust has absolutely weird setup with rustc-workspace-shim, which leads to real cycles.
* | | | Merge #519bors[bot]2019-01-135-11/+46
|\ \ \ \ | |_|/ / |/| | / | | |/ | |/| | | | | | | | | | 519: support ref-patterns r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | support ref-patternsAleksey Kladov2019-01-135-11/+46
| |/
* | Merge #513bors[bot]2019-01-133-35/+53
|\ \ | | | | | | | | | | | | | | | | | | | | | 513: Add bench runnable and code lens r=matklad a=kjeremy Co-authored-by: Jeremy Kolb <[email protected]>
| * | Add bench runnable and code lensJeremy Kolb2019-01-123-35/+53
| | |
* | | Merge #514bors[bot]2019-01-134-9/+16
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | 514: npm fix run r=matklad a=kjeremy Co-authored-by: Jeremy Kolb <[email protected]>
| * | npm fix runJeremy Kolb2019-01-124-9/+16
| |/
* | Merge #515bors[bot]2019-01-131-2/+2
|\ \ | |/ |/| | | | | | | | | | | 515: Fix typos r=matklad a=kjeremy Co-authored-by: Jeremy Kolb <[email protected]>
| * Fix typosJeremy Kolb2019-01-131-2/+2
|/
* Merge #505bors[bot]2019-01-1216-47/+398
|\ | | | | | | | | | | | | | | | | | | 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]>
| * args -> paramsFlorian Diebold2019-01-128-37/+37
| |
| * Small improvements from review commentsFlorian Diebold2019-01-123-20/+20
| |
| * Complete inherent methodsFlorian Diebold2019-01-123-4/+63
| |
| * Implement basic inherent method resolutionFlorian Diebold2019-01-1211-17/+309
| |
* | Merge #500bors[bot]2019-01-128-99/+173
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * | Move run_single into runnablesJeremy Kolb2019-01-124-66/+17
| | |
| * | Move `CargoTargetSpec` and friends to cargo_target_spec moduleJeremy Kolb2019-01-123-90/+102
| | |
| * | Code lens support for running testsJeremy A. Kolb2019-01-117-85/+196
| | |
* | | Do not recommend fetching whole repo for end usersPaweł Zmarzły2019-01-121-1/+1
| | | | | | | | | `--depth 1` will make a shallow clone, of master branch only.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-04 10:04:30 +0000