aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * | itroduce trait for ast tokensAleksey Kladov2019-01-0812-59/+34
|/ /
* | Merge #449bors[bot]2019-01-0861-3762/+2504
|\ \ | | | | | | | | | | | | | | | | | | | | | 449: switch to new rowan API r=matklad a=matklad closes https://github.com/rust-analyzer/rust-analyzer/issues/448 Co-authored-by: Aleksey Kladov <[email protected]>
| * | switched to published version of rowanAleksey Kladov2019-01-082-4/+3
| | |
| * | migrate ra_lsp_server to new rowanAleksey Kladov2019-01-081-1/+1
| | |
| * | migrate ra_analysis to new rowanAleksey Kladov2019-01-0812-78/+67
| | |
| * | migrate ra_hir to rowan 2.0Aleksey Kladov2019-01-0820-197/+238
| | |
| * | migrate ra_cli to new rowanAleksey Kladov2019-01-081-5/+5
| | |
| * | migrate ra_db to new rowanAleksey Kladov2019-01-083-11/+20
| | |
| * | migrate ra_editor to rowan 0.2Aleksey Kladov2019-01-0811-96/+83
| | |
| * | wrap TreePtrAleksey Kladov2019-01-082-16/+54
| | |
| * | regenerateAleksey Kladov2019-01-081-3052/+1791
| | |
| * | switch ra_syntax to new rowan APIAleksey Kladov2019-01-0815-327/+266
| | |
| * | update rowanAleksey Kladov2019-01-083-5/+6
|/ /
* | Merge #452bors[bot]2019-01-074-5/+18
|\ \ | | | | | | | | | | | | | | | | | | | | | 452: Process explicit type hints for str, bool and char r=flodiebold a=marcusklaas Co-authored-by: Marcus Klaas de Vries <[email protected]>
| * | Process explicit type hints for str, bool and charMarcus Klaas de Vries2019-01-074-5/+18
| | |
* | | Merge #451bors[bot]2019-01-077-50/+200
|\| | | |/ |/| | | | | | | | | | | | | | | 451: More type inference for more binary expressions r=flodiebold a=marcusklaas Implements more of https://github.com/rust-analyzer/rust-analyzer/issues/390. Just works for primitive (numeric) types for now. Found an issue where `let x: Ty = expr;` doesn't actually propagate the type information unless `Ty` is primitive and numeric. I'll open an issue for this. Co-authored-by: Marcus Klaas de Vries <[email protected]>
| * Tidy up binary operator type inference; add test fileMarcus Klaas de Vries2019-01-072-44/+87
| |
| * Implement type inference for more binary operatorsMarcus Klaas de Vries2019-01-074-49/+84
| | | | | | | | | | Mostly just for primitive numeric types such as u32 and f64. Not yet a general solution using trait resolution.
| * Add remaining binary operations to ASTMarcus Klaas de Vries2019-01-074-1/+73
|/
* Merge #450bors[bot]2019-01-076-43/+185
|\ | | | | | | | | | | | | | | 450: Implement autoderef for field accesses r=matklad a=flodiebold Which means we now get completion for fields e.g. in `&self` methods :) Co-authored-by: Florian Diebold <[email protected]>
| * Implement autoderef for field accessesFlorian Diebold2019-01-076-43/+185
|/
* Merge #442bors[bot]2019-01-076-57/+225
|\ | | | | | | | | | | | | | | | | | | | | | | 442: WIP: indent on typing dot r=matklad a=simonvandel Fixes #439. The unit test passes, but I can't seem to make VS code perform the action. The existing action on "=" doesn't work either on my end either though. I didn't add any smart way of detecting the current indent level. Any ideas how I would do that? Co-authored-by: Simon Vandel Sillesen <[email protected]>
| * my formatting tool locally messes things upSimon Vandel Sillesen2019-01-071-1/+1
| |
| * fix nitsSimon Vandel Sillesen2019-01-071-10/+8
| |
| * formattingSimon Vandel Sillesen2019-01-061-1/+1
| |
| * fix testsSimon Vandel Sillesen2019-01-061-10/+72
| |
| * add more testsSimon Vandel Sillesen2019-01-061-1/+54
| |
| * add "." as a trigger char on type formattingSimon Vandel Sillesen2019-01-061-1/+1
| |
| * refactorSimon Vandel Sillesen2019-01-062-35/+26
| |
| * format codeSimon Vandel Sillesen2019-01-061-1/+1
| |
| * rename unused variableSimon Vandel Sillesen2019-01-061-1/+1
| |
| * indent on typing dot. fixes #439Simon Vandel Sillesen2019-01-054-39/+103
| |
* | Merge #446bors[bot]2019-01-0715-426/+459
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 446: Use HIR Expr for type inference r=flodiebold a=flodiebold Now we can reuse the type inference inside a function when typing whitespace etc. :) The order of the lines in the type tests changed a bit, which I'm not sure why, but there are no actual changes in the inference results. Co-authored-by: Florian Diebold <[email protected]>
| * | if let -> matchFlorian Diebold2019-01-071-8/+6
| | |
| * | Improve types for node_expr / node_patFlorian Diebold2019-01-063-15/+11
| | |
| * | 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
| | |
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-25 01:26:08 +0000