| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
410: Detangle symbols r=matklad a=matklad
Previously, we used `FileSymbol` both to represent bytes which are stored in the index and as an API of `ra_analysis`. Mixing internal storage format and an API is not a really bright idea, so we introduce `NavigationTarget` to handle API part.
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
408: vscode problem matcher improvements r=matklad a=vemoo
The problem matcher wasn't working properly and looking at the rustc errors i realized it could be simplified.
I also added a new problem matcher that can be used with https://github.com/passcod/cargo-watch to get the errors in the editor on save. To use it one can create a tasks.json file with:
```json
{
"version": "2.0.0",
"tasks": [
{
"type": "shell",
"label": "cargo watch",
"command": "cargo",
"isBackground": true,
"args": [
"watch",
"-c"
],
"problemMatcher": [
"$rustc-watch"
]
}
]
}
```
I initially implemented it like this: https://github.com/rust-analyzer/rust-analyzer/commit/cff9f62d321a90c45e622f5304e60a248cbcf4f2 but i think there's a bug in vscode so i worked around it by copying the pattern for both problem matchers. The first commit can be used if https://github.com/Microsoft/vscode/pull/65840 is merged.
Co-authored-by: Bernardo <[email protected]>
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
407: run r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
406: Simplify r=matklad a=matklad
Get rid of `AnalysisImpl` wrapper around salsa database. It was useful before we migrated by salsa, but it's long have been just a useless boilerplate.
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
405: extend selection inside a string literal should select a word first r=matklad a=gfreezy
fixed #402
Co-authored-by: gfreezy <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
404: Move FileSymbol to ra_analysis r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
403: initial support for macros r=matklad a=matklad
I'll write a more comprehensive description when this is closer to being done. Basically this investigates one question: "how do we represent code which is a result of a macro call". This is an interesting question: currently everything is `FileId` based, but macro expansion does not have a file!
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|