| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
Needed to add a default crate graph in the analysis for that.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
rustc uses the name ImplItem for items in impls, not the impl {} block itself,
which could lead to confusion.
|
|\
| |
| |
| |
| |
| |
| |
| | |
425: remove id arena r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
424: remove non-doc comments from doc comments r=matklad a=csmoe
Closes #357
Co-authored-by: csmoe <[email protected]>
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
391: docing parser methods r=csmoe a=csmoe
Co-authored-by: csmoe <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
| | | |
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
420: unit-tests r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
419: file-id-to-symbol r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
418: field-vis r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
417: travis-compile r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
416: assist-builder r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | |
|
| |/ / |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
| | | |
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
413: add visibility owner, refactor assists r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
| | | |
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
412: vec-macro r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
409: Add Analysis#teype_of test r=matklad a=h-michael
Co-authored-by: Hirokazu Hata <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|