| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
| |
Wrap them in a LiteralPat node so they can be distinguished from literal
expressions.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
771: update notify with fix for hight cpu usage r=matklad a=vemoo
Should fix the ocasional 100% CPU hangs.
I've tried `yes > test.rs` which would cause it before, and now on my computer it stays below 10%, and stops as soon as I interrupt the command, unlike previously which would stay at 100% for a while.
Co-authored-by: Bernardo <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
767: Extract project model to separate crate r=matklad a=flodiebold
I'm looking into creating a separate crate that would allow getting a HIR db for a project for 'batch' analyses, and this seems to be an obvious first step. We'd probably want to change the error handling to not rely on failure, though, right?
Co-authored-by: Florian Diebold <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
766: Formatting code into ra_fmt r=matklad a=eulerdisk
As discussed https://github.com/rust-analyzer/rust-analyzer/pull/762#discussion_r254905885
I did only move the code without other improvements.
Co-authored-by: Andrea Pretto <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
768: Sort assists by the range of the affected element r=matklad a=robojumper
Closes #763.
https://github.com/rust-analyzer/rust-analyzer/blob/3be98f2ac93b278828e76eb813bdd8033f647b12/crates/ra_assists/src/lib.rs#L233-L236
This could be made more robust by a) adding a way to identify actions by things other than their label and b) allowing arbitrary actions to appear in the list as long as the tested actions are there in the correct order. Let me know if I should do any of that.
Co-authored-by: robojumper <[email protected]>
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
765: Jettison `imp` module r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
760: Add new assist to remove dbg!() calls r=matklad a=vipentti
This fixes #758.
Currently we try to maintain the cursor position relative to the statement under
cursor, if the cursor is inside the dbg! macro call.
Meaning:
```rust
let foo = dbg!(some.complex<|>().expression());
```
Should turn into:
```rust
let foo = some.complex<|>().expression();
```
With the cursor staying in place.
Co-authored-by: Ville Penttinen <[email protected]>
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes #758.
Currently we try to maintain the cursor position relative to the statement under
cursor, if the cursor is inside the dbg! macro call.
Meaning:
let foo = dbg!(some.complex<|>().expression());
Should turn into:
let foo = some.complex<|>().expression();
With the cursor staying in place.
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
761: Update npm packages r=matklad a=kjeremy
Co-authored-by: kjeremy <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
755: Add new configuration "enableEnhancedTyping" to control registering of "type" command r=matklad a=vipentti
This further fixes problems when having a VIM extension (at least vscodevim)
enabled, by not calling `overrideCommand('type', commands.onEnter.handle)` when
enableEnhancedTyping is set to `false`.
The problem is dependent on the order in which extensions are activated, if
rust-analyzer is activated before `vscodevim`, rust-analyzer will register the
`type` command, and when `vscodevim` finally attempts to activate, it will fail
to register the command. This causes `vscodevim` to stop working properly.
This setting allows users to disable the registerCommand `type` in
rust-analyzer, allowing `vscodevim` to work. The setting defaults to `true`.
Currently changing the setting requires reloading of the window.
Co-authored-by: Ville Penttinen <[email protected]>
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
"type" command
This further fixes problems when having a VIM extension (at least vscodevim)
enabled, by not calling `overrideCommand('type', commands.onEnter.handle)` when
enableEnhancedTyping is set to `false`.
The problem is dependent on the order in which extensions are activated, if
rust-analyzer is activated before `vscodevim`, rust-analyzer will register the
`type` command, and when `vscodevim` finally attempts to activate, it will fail
to register the command. This causes `vscodevim` to stop working properly.
This setting allows users to disable the registerCommand `type` in
rust-analyzer, allowing `vscodevim` to work. The setting defaults to `true`.
Currently changing the setting requires reloading of the window.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
754: Some clippy things r=matklad a=kjeremy
Co-authored-by: kjeremy <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
753: assists: compute edit r=matklad a=kjeremy
Fixes #751
Co-authored-by: kjeremy <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
752: cargo update r=kjeremy a=kjeremy
Removes a few crates from the dep chain.
Co-authored-by: kjeremy <[email protected]>
|
|/ / |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| | |
750: Move assists to a separate crate r=matklad a=matklad
I am slowly coming to conclusion that ide_api_light does not make a lot of sense after all :D
This PR moves assists to a separate crate, so that assists can use database (so, inspect types, do name-resolution, etc)
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
748: Fill deprecation for LSP r=kjeremy a=kjeremy
Co-authored-by: kjeremy <[email protected]>
Co-authored-by: Jeremy Kolb <[email protected]>
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
746: Rename assits to assists r=kjeremy a=kjeremy
Co-authored-by: Jeremy Kolb <[email protected]>
|