| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
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]>
|
| | | |
|
| | | |
|
|/ /
| |
| |
| | |
#1510
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
The new commands are
$ cargo install-ra --client-code
$ cargo install-ra --server --jemalloc
|
| |
| |
| |
| |
| |
| | |
Add hints for types in for loop expressions.
Resolve types for every tuple parameter.
Refactor the code.
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1584: switch to upstream unescape r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1583: :arrow_up: rowan r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |/ |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
1573: fix: parse box syntax inside parentheses r=matklad a=csmoe
r? @matklad
Co-authored-by: csmoe <[email protected]>
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1549: Show type lenses for the resolved let bindings r=matklad a=SomeoneToIgnore
Types that are fully unresolved are not displayed:
<img width="279" alt="image" src="https://user-images.githubusercontent.com/2690773/61518122-8e4ba980-aa11-11e9-9249-6d9f9b202e6a.png">
A few concerns that I have about the current implementation:
* I've adjusted the `file_structure` API method to return the information about the `let` bindings.
Although it works fine, I have a feeling that adding a new API method would be the better way.
But this requires some prior discussion, so I've decided to go for an easy way with an MVP.
Would be nice to hear your suggestions.
* There's a hardcoded `{undersolved}` check that I was forced to use, since the method that resolves types returns a `String`.
Is there a better typed API I can use? This will help, for instance, to add an action to the type lenses that will allow us to navigate to the type.
Co-authored-by: Kirill Bulatov <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| |\| |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|