| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1602: Assist to merge identical match arms r=matklad a=theotherphil
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/1250
Co-authored-by: Phil Ellison <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1604: Fix failing type interference for floating point literal r=matklad a=theotherphil
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/1592
Co-authored-by: Phil Ellison <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1601: Inline snapshots for tests r=matklad a=theotherphil
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/1127.
The "cargo format" commits are required to get the formatting tests to pass. However, they actually mess up the formatting.
Co-authored-by: Phil Ellison <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
idea)
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
check_completion
|
| | | |
|
| | | |
|
| |/
| |
| |
| | |
rename_mod_in_dir snapshot
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1621: Document AssistBuilder r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
| | |
| | |
| | | |
closes #1603
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1606: Add `if let`, `while let` and match arm inlay hints r=matklad a=SomeoneToIgnore
<img width="693" alt="image" src="https://user-images.githubusercontent.com/2690773/62013363-152f1d80-b19a-11e9-90ea-07568757baa2.png">
Add more inline hints support.
Looks like `while let` type inference support is missing currently, so the corresponding hint tests lack the actual results.
I've also could not find a good way to distinguish between `a` and `b` pats in the following expressions:
`if let Some(Test { a: None, b: y }) = &test {};`
In this case we don't need to add a hint for first pat (`a: None`), since it's matched against the particular enum variant and need a hint for `y`, since it's a new variable.
But both `a` and `b` are `BIND_PAT` with similar contents, so looks like there's nothing I can check for to find any differences.
I don't display any hints for such cases now, to avoid confusion, but would be nice to know if there's a way to fix this behavior.
Co-authored-by: Kirill Bulatov <[email protected]>
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1605: Resolve modules inside inline module r=matklad a=andreevlex
#1510
Co-authored-by: Alexander Andreev <[email protected]>
|
| | | | |
|
| |/ /
| | |
| | |
| | | |
#1510
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1617: document upgrade process r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
| | | |
| | | |
| | | | |
closes #1615
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1614: show prettier diff on CI r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
1610: Ignore cancelled inlay hints responses r=matklad a=SomeoneToIgnore
Fixes #1607
Co-authored-by: Kirill Bulatov <[email protected]>
|
| | | | | |
|
| | |/ /
| |/| | |
|
|\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1613: :arrow_up: npm r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |/ / |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
1611: install npm deps once r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1599: it's a good idea to build extension before installing it r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1597: Overhaul installation process r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ /
| |
| |
| |
| |
| |
| | |
The new commands are
$ cargo install-ra --client-code
$ cargo install-ra --server --jemalloc
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1596: Implement inlay hints for emacs r=matklad a=flodiebold
I wanted to have the nice type hints in emacs as well :smile:
![2019-07-27-111718_982x171_scrot](https://user-images.githubusercontent.com/906069/61992560-43104700-b060-11e9-879f-8ad60f71b2e5.png)
Co-authored-by: Florian Diebold <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1594: Improve inlay hinting for types r=matklad a=SomeoneToIgnore
Add hints for types in for loop expressions.
Resolve types for every tuple parameter.
Refactor the code.
![image](https://user-images.githubusercontent.com/2690773/61957524-2294ae00-afc8-11e9-8bdc-f86f9c84ab7e.png)
Co-authored-by: Kirill Bulatov <[email protected]>
|
|/ /
| |
| |
| |
| |
| | |
Add hints for types in for loop expressions.
Resolve types for every tuple parameter.
Refactor the code.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1586: Add type decorators r=matklad a=SomeoneToIgnore
A follow-up of https://github.com/rust-analyzer/rust-analyzer/pull/1549
Now the frontend shows inlay hints as VS Code Decorators:
<img width="666" alt="image" src="https://user-images.githubusercontent.com/2690773/61802687-918fcc80-ae39-11e9-97b0-3195ab467393.png">
<img width="893" alt="image" src="https://user-images.githubusercontent.com/2690773/61802688-93599000-ae39-11e9-8bcb-4512e22aa3ed.png">
A few notes on the implementation:
* I could not find a normal way to run and display the hints for the file that's already open in the VS Code when it starts.
The updating code runs ok, but does not actually show anything.
Seems like I miss some event that I could add a handler to.
I've also experimented with `setTimeout` and it worked, but this is too ugly.
The hints appear now when a new file is open or when some change is done in the existing file.
* If there's a `dbg!` used in the lsp_server, the frontend starts receiving change events that contain the string from the `dbg!` output.
It should not be the case in a real life, but I've decided to cover this case, just in case.
* For bigger files, ~500 lines, the decorators start to blink, when updated, this does not seem to be very much of a problem for me at this particular stage of the feature development and can be optimized later. In the worst case, those decorators can be turned off in settings.
* Cursor movement is rather non-intuitive on the right edge of the decorator.
Seems like a thing to fix in the VS Code, not in the plugin.
Co-authored-by: Kirill Bulatov <[email protected]>
|