| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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]>
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Also rename the files to remove the numbers (they don't serve a purpose now that
there are only the data files).
|
|/ /
| |
| |
| |
| | |
Now we can reuse the type inference inside a function when typing whitespace
etc. :)
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
447: Show types when hovering patterns as well r=flodiebold a=flodiebold
Co-authored-by: Florian Diebold <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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]>
|
| | |
| | |
| | |
| | |
| | | |
Also try to infer its subexpressions and set type expectations
whenever possible.
|
| |/ |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
445: kill module source r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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]>
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
|
| |/
| |
| |
| | |
This currently fails, but should work once we have hir::Expr.
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
443: split_import intention correctly works with use trees r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
438: show types in local variable hovers r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| | |
437: refactor goto defenition r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| | |
|