| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This seems to be enough to prevent hanging in rust-analyzer, Chalk and the rustc
repo.
|
| |
|
|
|
|
| |
fields
|
| |
|
| |
|
| |
|
|
|
|
| |
#1211
|
| |
|
|
|
|
| |
this is in preparation for the new rowan API
|
|\
| |
| |
| |
| |
| |
| |
| | |
1523: account for dependencies when showing memory usage r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| | |
1520: Ignore workspace/didChangeConfiguration notifications. r=matklad a=bolinfest
If the client happens to send a `workspace/didChangeConfiguration`
notification, it is nicer if rust-analyzer can just ignore it rather than
crash with an "unhandled notification" error.
Co-authored-by: Michael Bolin <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This appears to have been introduced ages ago in
https://github.com/rust-analyzer/rust-analyzer/commit/be742a587704f27f4e503c50f549aa9ec1527fcc
but has since been removed.
As it stands, it is problematic if multiple instances of the
rust-analyzer LSP are launched during the same VS Code session because
VS Code complains about multiple LSP servers trying to register the
same command.
Most LSP servers workaround this by parameterizing the command by the
process id. For example, this is where `rls` does this:
https://github.com/rust-lang/rls/blob/ff0b9057c8f62bc4f8113d741e96c9587ef1a817/rls/src/server/mod.rs#L413-L421
Though `apply_code_action` does not seems to be used, so it seems better
to delete it than to parameterize it.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Random drive-by fix. I honestly blame rust-analyzer itself on this,
because I set its watch mode to use `cargo clippy` :shrug:
|
|/
|
|
| |
Now that we are using a newer smol_str release this can be simplified :)
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1515: Trait environment r=matklad a=flodiebold
This adds the environment, i.e. the set of `where` clauses in scope, when solving trait goals. That means that e.g. in
```rust
fn foo<T: SomeTrait>(t: T) {}
```
, we are able to complete methods of `SomeTrait` on the `t`. This affects the trait APIs quite a bit (since every method that needs to be able to solve for some trait needs to get this environment somehow), so I thought I'd do it rather sooner than later ;)
Co-authored-by: Florian Diebold <[email protected]>
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
I.e. if we are inside a function with some where clauses, we assume these where
clauses hold.
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1512: Infer ? operator r=unrealhoang a=unrealhoang
Logical continuation of https://github.com/rust-analyzer/rust-analyzer/pull/1501
cc https://github.com/rust-analyzer/rust-analyzer/issues/1426
Co-authored-by: Unreal Hoang <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| |/
|/| |
|
|/ |
|
|
|
|
| |
closes #1474
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1504: Simplify LSP handlers r=matklad a=kjeremy
Takes advantage of protocol inheritance via composition and simplifies some responses via the `From`/`Into` traits.
Co-authored-by: Jeremy Kolb <[email protected]>
|
| | |
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1501: Infer for loop variable r=flodiebold a=unrealhoang
My take on https://github.com/rust-analyzer/rust-analyzer/issues/1425
Co-authored-by: Unreal Hoang <[email protected]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1499: processing attribute #[path] of module r=matklad a=andreevlex
support two cases
- simple name file `foo.rs`
- declaration in mod.rs
#1211
Co-authored-by: Alexander Andreev <[email protected]>
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
#1211
|
| |/
|/| |
|
| | |
|
|/
|
|
|
| |
E.g. if we call `foo<T: Into<u32>>(x)`, that adds an obligation that `x:
Into<u32>`, etc.
|