aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * | Introduce ArenaMapFlorian Diebold2019-01-065-25/+97
| | |
| * | Sort ranges in type inference testsFlorian Diebold2019-01-069-92/+93
| | | | | | | | | | | | | | | Also rename the files to remove the numbers (they don't serve a purpose now that there are only the data files).
| * | Use HIR Expr for type inferenceFlorian Diebold2019-01-0610-342/+308
|/ / | | | | | | | | Now we can reuse the type inference inside a function when typing whitespace etc. :)
* | Merge #447bors[bot]2019-01-061-4/+15
|\ \ | | | | | | | | | | | | | | | | | | | | | 447: Show types when hovering patterns as well r=flodiebold a=flodiebold Co-authored-by: Florian Diebold <[email protected]>
| * | Show types when hovering patterns as wellFlorian Diebold2019-01-061-4/+15
|/ /
* | Merge #440bors[bot]2019-01-064-2/+140
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 440: Implement type inference for boolean operators r=flodiebold a=marcusklaas Tried implementing the easiest part of https://github.com/rust-analyzer/rust-analyzer/issues/390. Hope this is somewhat close to what the intent of the issue was. Found it surprisingly easy to find my way around the repository - it's well organized! Very grateful for any pointers. Co-authored-by: Marcus Klaas de Vries <[email protected]>
| * | Touch up type inference for boolean operatorsMarcus Klaas de Vries2019-01-066-43/+93
| | | | | | | | | | | | | | | Also try to infer its subexpressions and set type expectations whenever possible.
| * | Implement type inference for boolean operatorsMarcus Klaas de Vries2019-01-056-4/+92
| |/
* | Merge #445bors[bot]2019-01-068-194/+156
|\ \ | | | | | | | | | | | | | | | | | | | | | 445: kill module source r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | kill module sourceAleksey Kladov2019-01-068-194/+156
|/ /
* | Merge #429bors[bot]2019-01-0621-709/+790
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 429: Reorganize hir public API in terms of code model r=matklad a=matklad Recently, I've been thinking about introducing "object orient code model" API for rust: a set of APIs with types like `Function`, `Module`, etc, with methods like `get_containing_declaration()`, `get_type()`, etc. Here's how a similar API might look like in .Net land: https://docs.microsoft.com/en-us/dotnet/api/microsoft.codeanalysis.semanticmodel?view=roslyn-dotnet https://docs.microsoft.com/en-us/dotnet/api/microsoft.codeanalysis.imethodsymbol?view=roslyn-dotnet The main feature of such API is that it can be powered by different backends. For example, one can imagine a backend based on salsa, and a backend which reads all the data from a specially prepared JSON file. The "OO" bit is interesting mostly in this "can swap implementations via dynamic dispatch" aspect, the actual API could have a more database/ECS flavored feeling. It's not clear at this moment how exactly should we implement such a dynamically (or if we even need dynamism in the first pace) swapable API in Rust, but I'd love to experiment with this a bit. For starters, I propose creating a `code_model_api` which contains various definition types and their public methods (mandatory implemented as one-liners, so that the API has a header-file feel). Specifically, I propose that each type is a wrapper around some integer ID, and that all methods of it accept a `&db` argument. The actual impl goes elsewhere: into the db queries or, absent a better place, into the `code_model_api_impl`. In the first commit, I've moved the simplest type, `Crate`, over to this pattern. I *think* that we, at least initially, will be used types from `code_model_api` *inside* `hir` as well, but this is not required: we might pick a different implementation down the line, while preserving the API. Long term I'd love to replace the `db: &impl HirDatabase` argument by a `mp: &dyn ModelProvider`, implement `ModelProvider` for `T: HirDatabase`, and move `code_model_api` into the separate crate, which does not depend on `hir`. @flodiebold you've recently done some `Def`s work, would do you think of this plan? Could it become a good API in the future, or is it just a useless boilerplate duplicating method signatures between `code_model_api` and `code_model_impl`? Co-authored-by: Aleksey Kladov <[email protected]>
| * | move submodule computationt to module_treeAleksey Kladov2019-01-064-53/+39
| | |
| * | fix the testAleksey Kladov2019-01-061-2/+2
| | |
| * | fix after rebaseAleksey Kladov2019-01-061-1/+2
| | |
| * | flatten module structureAleksey Kladov2019-01-0613-436/+431
| | |
| * | adjust commentsAleksey Kladov2019-01-062-5/+8
| | |
| * | fix ra_analysis to work with the new APIAleksey Kladov2019-01-064-7/+12
| | |
| * | split module source into decl/definAleksey Kladov2019-01-066-32/+106
| | |
| * | kill old moduleAleksey Kladov2019-01-067-233/+66
| | |
| * | add parent & resolve_pathAleksey Kladov2019-01-064-5/+67
| | |
| * | make source cancelableAleksey Kladov2019-01-061-2/+2
| | |
| * | make deps cancelableAleksey Kladov2019-01-062-3/+3
| | |
| * | fix testsAleksey Kladov2019-01-064-20/+42
| | |
| * | switch source-binders to ModuleAleksey Kladov2019-01-062-9/+20
| | |
| * | Start code_model::ModuleAleksey Kladov2019-01-064-7/+83
| | |
| * | move crate to code_model_apiAleksey Kladov2019-01-063-21/+34
|/ /
* | Merge #441bors[bot]2019-01-0620-254/+1150
|\ \ | | | | | | | | | | | | | | | | | | | | | 441: hir::Expr r=matklad a=flodiebold Still a bit to do, but I already adapted `FnScopes` and thought I'd get feedback already. Co-authored-by: Florian Diebold <[email protected]>
| * | Add fn signature queryFlorian Diebold2019-01-068-7/+86
| | |
| * | Various small code review improvementsFlorian Diebold2019-01-053-26/+27
| | |
| * | Make FnScopes use hir::ExprFlorian Diebold2019-01-0513-313/+533
| | | | | | | | | | | | | | | | | | This was a bit complicated. I've added a wrapper type for now that does the LocalSyntaxPtr <-> ExprId translation; we might want to get rid of that or give it a nicer interface.
| * | Add HIR Expr machineryFlorian Diebold2019-01-059-4/+542
| | |
| * | Add test for invalidation of inferred types when typing inside functionFlorian Diebold2019-01-052-0/+58
| |/ | | | | | | This currently fails, but should work once we have hir::Expr.
* | Merge #443bors[bot]2019-01-061-1/+13
|\ \ | |/ |/| | | | | | | | | | | 443: split_import intention correctly works with use trees r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * split_import intention correctly works with use treesAleksey Kladov2019-01-061-1/+13
|/
* Merge #438bors[bot]2019-01-054-89/+76
|\ | | | | | | | | | | | | | | 438: show types in local variable hovers r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * fix testsAleksey Kladov2019-01-053-79/+49
| |
| * show types in local variable hoversAleksey Kladov2019-01-052-10/+27
| |
* | Merge #437bors[bot]2019-01-056-212/+138
|\| | | | | | | | | | | | | | | 437: refactor goto defenition r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * kill approximatelly_resolve_symbolAleksey Kladov2019-01-054-90/+11
| |
| * inline goto_defention testsAleksey Kladov2019-01-053-66/+58
| |
| * move goto_defenition to a separate fileAleksey Kladov2019-01-053-11/+91
| |
| * introduce separate goto_defenitionAleksey Kladov2019-01-052-3/+9
| |
| * kill accidentally added fileAleksey Kladov2019-01-051-73/+0
|/
* Merge #436bors[bot]2019-01-053-1/+13
|\ | | | | | | | | | | | | | | 436: Allow user to set path to ra_lsp_server in vscode settings r=matklad a=gentoo90 Co-authored-by: gentoo90 <[email protected]>
| * Allow user to set path to ra_lsp_server in vscode settingsgentoo902019-01-053-1/+13
| |
* | Merge #435bors[bot]2019-01-054-161/+204
|\ \ | |/ |/| | | | | | | | | | | 435: Refactor hover r=matklad a=matklad Primaraly this moves `hover` to `ra_analysis`, so that we finally can write tests for it! Co-authored-by: Aleksey Kladov <[email protected]>
| * move typeof to hoverAleksey Kladov2019-01-053-18/+18
| |
| * fold doc_comment into hoverAleksey Kladov2019-01-053-109/+110
| |
| * move hover implementation to ra_analysisAleksey Kladov2019-01-054-67/+83
| |
| * wipAleksey Kladov2019-01-051-0/+26
|/
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-28 10:25:47 +0000