370: Self params & type r=matklad a=flodiebold
This implements type inference for `self`, so field completion for methods taking `self` works now.
- rename `IMPL_ITEM` to `IMPL_BLOCK` -- rustc calls the methods etc. inside an impl `ImplItem`s, and the impl itself doesn't define an item, so I thought this name was clearer.
- add HIR for impl blocks -- we collect all impls in a crate at once, so we can go from methods to containing impls, and since we will later also need to find all impls for a certain type (which may be anywhere in the crate, I think?). We could be more lazy here, but I don't know if it's worth the complexity.
- resolve `self` and `Self` during type inference
- refactor a bit in ty.rs as well
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Since we need to be able to go from def to containing impl block, as well as the
other direction, and to find all impls for a certain type, a design similar to
the one for modules, where we collect all impls for the whole crate and keep
them in an arena, seemed fitting. The ImplBlock type, which provides the public
interface, then consists only of an Arc to the arena containing all impls, and
the index into it.
426: Rename ImplItem to ImplBlock r=flodiebold a=flodiebold
rustc uses the name ImplItem for items in impls, not the impl {} block itself,
which could lead to confusion.
Extracted from #370.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
421: Index macros r=matklad a=matklad
So, this is pretty cool! We now index items which are the result of macro expansion! (of a single currently hard-coded macro). So, workspace symbols can now be used to navigate to `HirDatabase`, for example
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
415: use LSP file system operations r=matklad a=vemoo
implements #131
I've replaced `source_file_edits` and `file_system_edits` with `workspace_edit` because [`WorkspacEdit`](https://docs.rs/languageserver-types/0.53.1/languageserver_types/struct.WorkspaceEdit.html) can represent both.
I only use `document_changes` because `changes` cannot represent file system operations.
But if the client doesn't have the `workspace.workspaceEdit.resourceOperations` capability `WorkspaceEdit` cannot replace the current `FileSystemEdit`. Can we assume that the client will support it?
I also adapted the extension code to make use of the new response type, but only for vscode, i don't know if changes have to be made for the emacs part.
Co-authored-by: Bernardo <berublan@gmail.com>
